Agile management - JIRA使用入门

Introduction

Jira is one of the most flexible most powerful Agile team management tools that there is. All that power is its greatest strength - maybe also it’s its greatest weakness. Jira can be a little overwhelming at first. But just a few key things will get you pretty far toward harnessing安上马具，引申为驾驭 the power of it all.

I’m Dan Chuparkoff and today I’m putting those key things you need to master Jira and Agile team management all here in this video so you and your team don’t have to stumble through it on your own.

ELements

Projects

• The JIRA project is the highest level container. You can think of the Jira project as a table in a database.

• A single Jira issue can only exist in one Jira project at a time.

From Jira’s home dashboard you can see your projects by clicking the projects menu over there in the left navigation bar.

From this projects listing page you can see and access your existing projects or you can create a new Jira project just by clicking the create project button at the top right. That’s enough to get you started.

But while we’re here, don’t get too caught up in the actual definition of the word project. When Jira was created back in 2003, the word project often referred to a much bigger collection of work - sometimes stretching over years of development.

These days, projects are much more Agile. Your team is probably juggling lots of project work. Don’t let the semantics of that word lure引诱 you into scattering分散 your team’s work into a million different fragments. Trust me. Put all of your team’s work into a single Jira project.

We’ll use some of the other attributes of Jira to allow you to divide it up into contextual views. I’ll explain this a lot more in the sections later in this video on Epics, Components, Labels, and Boards.

Types of Agile

Next, let’s talk for a second about the types of Agile.

As you create your first new Jira project, you’ll notice that you have a few options for what happens next.

25
00:01:35,259 --> 00:01:37,989
you’ll notice that you have a few options for what happens next.

There are two fundamental styles of Agile work management: Kanban and Scrum.

Don’t worry. This is an easy distinction once you understand the basics. Here’s a quick and easy breakdown of each so that you can quickly and confidently find the work style that will set your team up for success.

Kanban Agile

• The first flavor of Agile is known as Kanban. Kanban Agile is best for teams that are working on bugs or issues where most issues have a flexible - or more commonly an ‘as soon as possible’ (ASAP) delivery schedule. In Kanban, there’s a focus on rapid assignment and working in the right order and not as much on estimating projected completion dates for every piece of work.
  • Imagine you’re working on a team like a customer support or operations team in which the majority of your work comes from customer-submitted issues or tickets. New issues are reported frequently and some of them require an incredibly urgent turnaround. Other lower priority issues can be addressed on a lengthier timeline. The fluid nature of Kanban helps these teams achieve their need to react with varying speed at varying times.
  • In cases like this,
    • teams collect all the work that needs to be done,
    • they put the work in the right order,
    • and they assign it and complete the work as fast as they can.
  • That’s Kanban.
  • To create a new Kanban project, just name your new project and then click the change link to select the Kanban workflow template from the list. That’s it. Now you have a Kanban project.

Scrum Agile

Scrum Agile is best for teams that are working on new features with a tight schedule for finishing their work as they try to align with a projected launch target or the coordination with delivery from other teams.

Scrum teams manage their way toward this projected target by breaking their work up into iterative batches that we call Sprints.

Most high-performing teams agree that two weeks is a good length of time for Sprints.

Imagine you are working on a software team implementing new features. In this case, a large amount of your work is defined in a Backlog near the beginning of the project and you’re most likely working toward an incremental milestone or the ultimate projected launch date. Your team will still encounter unknowns and you will, of course, still learn new things along the way. So it’s normal, acceptable, and even encouraged to refine and redefine some of your work as you proceed. But an important distinction here is that when new work is discovered in the middle of an active Sprint, the existing in-progress work is left to proceed as it is and that new work is added to the next Sprint. Because you’re Agile, that next Sprint should be right around the corner. So to summarize: in Scrum, teams collect all the work that needs to be done, they put the work in the right order, they define checkpoints for completion of batches of that work, and then they reprioritize at each checkpoint. That’s scrum. And each of those iterative batches of work is a Sprint. Creating a new Scrum project is even easier in JIRA. After you name your new project, you’ll notice that the Scrum workflow template is already the default option. Just click the Create button and you’ll be off and running. Now we have a project in JIRA, but it’s empty. So we’re going to create some issues. In all kinds of Agile, teams break their to-dos down into small manageable snippets. This breaking of work into fragments helps to ensure that ownership of every task is clear and that teams can reprioritize as often as their w