Overview Problem Scenario Sprint

Loading...

來自 University of Virginia 的課程

Agile Development in Practice (Project-centered Course)

89 個評分

University of Virginia

Agile Development in Practice (Project-centered Course)

89 個評分

課程 5（共 5 門，Specialization 敏捷开发）

This project-centered course provides a guided opportunity for you to practice your agile development skills. Using the venture design process that frames the four courses in this Specialization, you will apply agile processes to a project of your choice or to a provided venture concept. From persona, problem scenario, and user story development to designing user testing and product launch, you’ll practice leading an agile project. You’ll finish the course with a portfolio-building design brief that demonstrates your learning and specialized skills in agile product development. To get the most out of this course, we suggest you first complete the other four courses in the Agile Development Specialization: Agile Meets Design Thinking; Running Product Design Sprints, Managing an Agile Team, Testing with Agile. By the end of this course, you'll be able to: --Formulate foundational positioning statements --Create, refine and test actionable personas --Conduct user interviews and analyze the results --Determine a 'happy path' to quickly test user stories --Run motivation and usability testing and evaluate the results As a Project Management Institute (PMI®) Registered Education Provider, the University of Virginia Darden School of Business has been approved by PMI to issue 40 professional development units (PDUs) for this course, which focuses on core competencies recognized by PMI. (Provider #2122) This course is supported by the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.

從本節課中

Complete Persona Discovery

Welcome to Week 3. This week, you'll continue working on persona development by interviewing at least three people. As you process the transcripts, look for key learnings and share these in the discussion forum, noting how these interviews impact your direction and point of view. If you want to accelerate your learning, interview at least three more learners and complete a "Day in the Life".

Getting People to Interview7:10

Talking with Users4:51

Skit: Interviewing Trent the Technician5:45

Overview Problem Scenario Sprint5:23

與講師見面

Alex Cowan
Faculty & Batten Fellow
Darden School of Business

Here we're going to go through an overview of the problem scenario sprint.

So this deals with this critical area where we figure out who is our user,

what makes them tick, and what do they actually care about?

So that the software we deliver is valuable to them in that it solves a job,

a desire, a habit that they actually have.

Now we're just going to run through this at a very high level as kind of a preview

of what's going to come in the subsequent module that's all about

the problem scenario sprint.

The concepts that are going to be important are, of course, personas.

So drafting them, think, see, feel, do.

Problem scenarios, these structured ideas about what actual jobs, habits,

desires they have at the present moment, and then drafting the interview guide.

And of course we're also going to be writing user stories at the end as we will

all of this sprints.

So that's a critical skill set.

And then in Module 2 itself of this course, we're going to talk

about the practice of going out and finding subjects and interviewing them.

And so on day 0, you're prepped.

Probably the single biggest thing is this whole business of thing

around getting subjects.

So having a good screener, who are these people, how are you going to get them,

practicing your interview technique.

That's what's really probably the most critical thing on prep for this sprint.

The brief, what is the input into the sprint?

How do you establish a charter in definition of success that's actionable,

valuable and that your team will understand?

It'll generally have this basic syntax that you see here, so we want to learn

how certain persona or segment does this certain thing in this problem area.

And we want to do that because we have some sort of idea of presumably,

of something we're going to do with software to make that better.

And we're going to deliver these certain things that are going to help us do that.

So early on at HVAC in a Hurry when they're still learning about what

does it mean to make our technicians more efficient with software, a good charter

with kind of adequate abstraction and specificity might be something relatively

general like, we want to learn how HVAC technicians prepare for and complete jobs.

It's pretty general, but that's okay, because that's where they're starting.

And they're doing this because they want to understand the company's learned

best practices and exploit opportunities to

encapsulate those into software and operationalize them for the technicians.

And they're going to deliver personas, problem scenarios, and

some preliminary user stories.

So they'll make sure that they have a nice clear view of who these people are and

what makes them tick and then they're going to drive to some ideas

about what that might look like with software.

Even if they're going to go forth and do another sprint,

they want to constantly make sure that they're thinking about where would we

go with this, how would we execute against this understanding we just acquired.

Here's another brief where maybe the HVAC in a Hurry team is, later on in the game,

because remember, these aren't just things you do at the beginning and

then check the box and they're done.

They are things that you come back to whenever you have

this type of specific question that's pertinent to the sprint type.

So maybe now they found that they want to learn it all about how these guys and

women technicians go out and get replacement parts to jobs.

And how the technicians work with the central office,

their support system to go get that done, how does all that work?

Because they want to look at whether they could automate

the things that work best with software.

The general outputs are the same.

Enable Quiz is the startup we've been playing with in our examples, and

a charter for them might be, well,

we want to learn how companies that hire engineers screen or do their preliminary

screening around these kind of hard skills of engineering topics, basically.

Because we think there might be an opportunity to introduce a quizzing system

that'll empower the in charge manager to help more with this process and

get better outcomes for everybody, including the candidates.

So those are some examples of what the brief might look like.

On day 1, as we discussed in course one with personas in problem scenarios,

we're going to push ourselves to see what we know and

understand what we want to get to with these materials.

And we're going to create, we're going to draft personas and

problem scenarios from what we know.

We're going to create an interview guide, we're going to practice it.

And then we're going to arrange the logistics to send everybody out

to talk to actual real users the next day, the next few days, in fact.

Days 2, 3 and 4, we're going to be out doing user interviews,

talking to real customers, making notes, taking note of our insights.

And then on day 5, we're going to comeback into the office and

we're going to share those things.

We're going to do structured sessions to evaluate what we've learned, encapsulate

it, make sure that,for instance, those transcripts are highly usable and

something that we can look back on 30, 90, 180 days and then drive to some stories.

What have we learned?

If we had to write software next week,

which you very well might, what would be our user stories?

What would we go implement based on what we learned?

That's how you'll wind up this sprint.

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2019 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取