1. Trang chủ
  2. » Công Nghệ Thông Tin

Head First Software Development phần 3 pps

48 176 0
Tài liệu được quét OCR, nội dung có thể không chính xác

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Gathering Requirements
Trường học University of Software Development
Chuyên ngành Software Development
Thể loại Bài tập
Năm xuất bản 2023
Thành phố Hanoi
Định dạng
Số trang 48
Dung lượng 3,22 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

with your total project estimate Yex've got an estinate Tor eath story now Add an estimate to each user story for how long you think it will take to develop thar functionality [1 Ate up

Trang 1

gathering requirements

© Finding hotes in ctarity

ReFing your see

stories

© Play planning poker

you are here » 64

Trang 2

Who a m

‘Abunch of techniques for working with requirements, in full S Ip

costume, are playing a party game, "Who am I?" They'll give you ol; u tỉ on

I'S

a clue and then you try to quess who they are based on what

they say Assume they always tell the truth about themselves Fill

inthe blanks next to each statement with the name (or names)

of each attendee thatthe statement is true for Attendees may be

Used in more than one answer

| help you capture EVERYTHING,

| help you get more from the customer

In court, 'd be admissible as firsthand

evidence

‘Some people say I'm arrogant, but really 'm

just about confidence

Everyone's involved when it comes to me

Did you say planning

poker? Customers dren’ involed in that activity

62 Chapter2

Trang 3

with your total project estimate

Yex've got an estinate

Tor eath story now

Add an estimate to each user story for how long you think it will take to develop thar functionality

[1 Ate up att the estimates to get.a total estimate for hos

long your project will uke to deliver the required software, <—>

Now you can +

ĐI nha And the total pede estimate is

Trang 4

489 days for the project?

‘That's almost two years!!!

No kidding! That's way too long,

By the time youve developed the software, my competition will have beaten us into the ground!

What do you do when your estimates

are WAY too long?

You've finally got an estimate you believe in, and

that takes into aecount all the requirements that the

customer wants, But you've ended up with a monster

project that is just goin, 1a take too long,

Is it time to go back to the drawing board? Do you

admit defeat and hand the work over to someone

eke? Or do you just ask the customer how long he

thinks would work, forgetting about all your hard

work to come up with you estimates in the first place?

You'll have to solve a crossword puzzle and work

your way to Chapter 3 to find out how to get Orion's

Orbits back on tack

64 Chapter2

Trang 5

gathering requirements

S&B Requirements and Estimation Cross

Let's pul what you've learned lo use and stretch out your left brain a bit, All of the words below are somewhere in this chapter: Good luck!

'3, When coming up with estimates, you are trying to get rid of as 5, User stories are written from the perspective ofthe

many 88 possible 6, When you and the customer act out a particular user story,

4, None ofthis language is allowed in a user story you are

7 Wa requirement is the what, an estimate is the 8 When everyone agrees on an estimate, itis called a

9 Requirements are oriented towards the 410 An estimate is good when eveyone on your team is

12 The best way to get honest estimates and highlight feeing

assumptions ‘1, The maximum number of days that a good estimate should

414, AUser Story is made up of and a description 45, ou 8 @ great way of getting frst hand evidence of exactly 13, A great user story i about ines long be for one user story,

how your customer works atthe moment 16, After around of planning poker, you plot all ofthe estimates

17 You can use the rule for breaking up large user stories,

you are here > 68

Trang 6

your software development toolbox

Tools for your Software Development Toolbox Software Development is all about developing and

delivering the software that the customer actu:

wants In this chapter, you learned about several techniques to help you get inside the customer's head and capture the requirements that represent what they really want For a comp! t of tools in the book, see Appendix ii

Development Techniques

Bluesky, Observation and Releplay

1 Blueskying gets your

Planning poker for estimation custome when coming up with thet to think big

‘= User stories should be short, around sentences in length

estimatable user story Auser story should not take cone developer more than 15, days to deliver

iteratively develop your requirements with your customer to keep them in the loop at every step of the process

66 Chapter2

Trang 8

Really darling, my software

development is so well planned Til

be home on time every day for us

to watch NASCAR together!

Every great piece of software starts with a great plan

In this chapter you're going to learn how to create that plan You're going to learn how to

work with the customer to prioritize their requirements You'll define iterations that you

‘and your team can then work toward Finally youll create an achievable development

plan that you and your team can confidently execute and monitor By the time you're

done, you'll know exactly how to get from requirements to your first deliverable

this is a new chapter 69

Trang 9

deliver what you can, when it's needed

Customers want their software NOW!

want (heir sofiware when they need it, and nota moment Lat

ips with the eu

#14p The total after summing up all the 90 days!

estimates for your user stories

70 Chapter3

Trang 10

Orion's Orbits stil wants to modernize their booking system; they just can't wait almost two years forthe software to get finished Take the folowing snippets from the Orion's Orbits user stories, along with their estimatas, and circa the ones you think you should develop to come up with chunk of work that will take no longer than 90 days,

vrs Booka shottle ‘wie Pay with Visa/MC/PayPal

“etal ebmate ter 4Ì

of the wer we Jue eile + this approach? Write See any problems with tm down here

Trang 11

priorities come from your customer

Our A Orion's Orbits still wants to modernize their booking system; they just can't wait for a year and

a half for the software to turn up Your job was to take the snippets on page 71 and keep the

‘ones you think you should develop Here are the stories we kept

"` “Ñ 4 tron if he imate, 15 đãƒt [gE sng to

Tờ xe ba se Pay with Visa/MC/PayPal bookings at al

& Yum Book Seaway in space-port We

imate I5 days transport BA duy neh

sounded eel! This is how long things ook when we added vp

all the estimates )

oxld Fit Bie

ee into fill | mẽ View Srace Miles Account

cut the 40 days

peer Ss ‘The customer sets the priorities

Seems like the CEO of Orion's Orbits is not

happy, and ean you blame him? Afterall that hard work to igure out what he needs, we've som > ignoted him completely when deciding which

user stories take priority for the project

l When user stories are being prioritized, you

customer knows what i really needed, So when

it comes to deciding what's in and what’s

‘out, you might be able to provide some expert help, but ultimately it’s a choice that the customer has to make

T2 Chapter 3

Trang 12

Prioritize with the customer

Is your customer's call as to what user stories take priority: To

customer make that decision, shullle and lay out

the table Ask your customer to order the user sto

st important to them fist) and d

to be delivered in Milestone 1.0 of their software

4p the Your user story cards on

‘Avser willbe able to Bescroton: A user will beable to Besetplem, Â ĐBF VI

vot a flight they have leave they have been on, a review for a shuttle flight shoose aisle or window

————

Users will be abe fo ‘Avaee will beable Beeaglem Austr Wil

Ir bookings by credit Specify the meals and drinks they roche poritia sett

Lay out all your user stories tal sik the noone to

Milestone 1.0 is your first major release of the software to the customer, Unlike

smaller iterations where you'll show the customer your software for feedback, this

\will be the first time you actually deliver your software (and! expect to get paid for

the delivery) Some Do's and Don'ts when planning Milestone 10:

DO issstetiecetincttonlity si cslexee impatience

be done in the time

ke it into Milestone 1,0 are not nil Milestone 2, or 3

>

Don't ce caught planning nice-to-haves

Milestone 1.0 is about delivering what’s needed, and that means set

of functionality that meets the most important needs of the customer

ME suy dau km (yet) user stories Don’t get caught up on how long those user stories will Artis point youve tanking cudomer hít ane th ớt inpodadl 3729 A were not cttimation

take to develop You're just trying to understand the customer's priorities Néll ome

right back

te this

youarehere > 73

Trang 13

Sanity-check your Milestone 1.0 estimate

a know whi jer Wants in Milestone 0,

nd out if you tí ngih of project if you

deliver all of th features

‘All of the user stories

Add together all meet

Trang 14

If the features don’t fit, reprioritize

You've got 274 days of work for Milestone 1.0, and Orion's Orbits want delivery in 90 days

Don't worry, this i pretty common, Customers usually want more than you can deliver,

‘your job to go back to them and reprioritize until you come up with a workable feature s

To reprioritize your user stories for Milestone 1.0 with the custome!

3 nats ne citerance between 2

milestone and a version?

Asner ntetyoucousal yor tek rset rae The

big diference between a milestone and a

which you deliver signicant software and get

paid by your customer, whereas aversion

is more of a simple descriptive term thats

used to identity a particular release of your

software

‘The diference i realy quite subtle, but the simple way to understand iti that Version”

is labol and doesnt mean anything mere,

whereas "Miestone' means you delver

signficanttunctonalty and you get pid

could be that Version 1.0 coincides with

Milestone 1.0, but equal Milestone 1.0

could be Version 0,1, 0.2 or anyother abel

you pek

Ship a milestone build as early as possible

anit milestone build of your software as ¢

Focus on the BASELINE functionality

Milestone 1.0 is all about delivering just the functionality

working version of the software

to oad, edit, and save a document with text init, aword processor simply is not useful,

‘Thats the rule of thumb: f you can get

by without a feature, then itisnt really baseline functonalty, and is probably a (ood candidate for pushing out to a later milestone than Milestone 1.0 if you don't have time to get everything done,

ceded for a

everything they originally said they dd

sy as possible This keeps your

m to focus on a dead that’s pot too far ol

Ce Dot let customers talk {yor inbo longer development

tyeles thân you're

Comfortable with The sooner

sr deadline, the more

Pesce you and your team tan be on it

led for later

3: te done the math and no matter how I cut the user stories up, | just can't deliver what my customer wants when they want me to, What can | do?

A? wine cas try

Tequied in the time that its needed by, and your customer simply won't budge when it

‘comes to removing some user stories from the mix then you might need to walk away from the project and know that atleast you were honest wit the customer

‘Another option isto ty to beef up your team

‘with new people to try and get more work done quicker However, adding new people

to the team wil up the costs considerably,

‘and won't necessarily get you all the

‘advantages that you'd think it might

Trang 15

factoring in toam performance

76 Chapter 3

IF it takes you 273 days, with 2 more eotle like you, that would vedute the overall development time by a factor

Finally, every person you add to your team makes the job of keeping everyone focused and knowing what they are doing harder; Keeping, everyone moving in the same direction and on the same page become a full-time job, and as your team gets larger you will find that

Mì start to hit your team’s averall ability to

this complex communi

be productive and develop great software

In fact, there isa maximum number of people that your team ean contain and still be productive, but i will depend very much on your project, your team, and who you're adding, The be

‘monitor your team, and if you start to see your team actually get less productive, even though you have more people, then it’ time to re-evaluate the amount of work you have to do or the amount of time in

approach is to

Which you have to do it

Later on in thit chapter you'll be introduced

Me ‘tool for monitoring the ria sella of Your to the bum-down vate graph This ix a great

team

Trang 16

More people sometimes means diminishing returns

‘Adaling more people to your team docsn'talways takes 2/4 days to complete Milestone 1.0, then $ people wont necessarily take 91 Ìn work as youd expect, If person

fact they could actually tale much longer! Teke'a ook perormance doesn’ abaya, inerease withthe size of your tea DÝđ3 se point,

Aboct here, your team's performance starts to max out

For small Leams, and

when startup and

setup time is factored

1 im You Can see 2 bi

QQ tetnere a maximum team size htt should never go over?

‘A ecm cere may fn that you can happily handle a 20-peson team, pata POWER RAL

but that things become impossible when you hit 21

‘Alternatively you might fin that any more than three Do you think the size of your project affects developers, and you start to see a dip in producti The this graph? What about if you broke your

project up into smaller sub-projects?

best approach is to monitor performance closely and

you arehere» T7

Trang 17

building achievable milestones

Work your way to a reasonable Milestone 1.0

With Orion’s Orbits, going from one person to three

more developers —ca

works out

First you add two new peo}

Adding two developers to your team (that’s

by adding two hhave a positive impact So let’ see how that

hen you reprioritize with the customer

te out what has to be removed We've got 189 days of work

3 days of work So we need to talk to the customer and remeve around £4 days

‘of work by shifting out some user stories from Milestone 1.0

sors airs wh case?

A tie oat esate oer acy have ote exact 188 days Given that we'e dealing with estimates anyway, which are

rarely 100% accurate, an that we tnd tobe shghly optimistic n

‘ur estimates then 165 days is close enough to the 189-day mark to be reasonably confident of delivering in that te

Looking better, with a few days

left over to give you a bit of breathing naặc in your milestone

sow ad you come up wth 190 days when you added

two new developers?

do around 190 days of work in 90 calendar days There are ways to backup this guess with some evidence using something called

“team velocity," but we'll get back to tha ater on inthis chapter

of work left

Trang 18

Functionality [f a feature isn't

BE the Cusfemer <_— _ events, 2 probably net a 10

Now it’s your chance to be the customer You need to build

a plan for when you are going to develop each of the user stories for Milestone 1.0, and to do that you need to ask the customer what features are most important so that you

can develop those first Your job is to play the eustomer

by men a priority to the Milestone 1.0 user stories

For each user story, assign it a ranking in the square provided, depending on how Đệ tho think that feature is using the Key at the bottom of the page

Order In-flight meals

sree View flit

20 đ rite (oh

-

+0 eon 12 days specify what priority it ám the box pronded

Trang 19

your customer decides priority

“BE the Customer Selufion Dumb Questions

‘Your job was to play the customer and prioritize the

Milestone 1.0 user stories Here are the priorities +40, and 50? 5 wy are te priorities 10, 2,20 that we assigned to each of the user stories

‘We also [aid out the user stories in order of A\: ower ot ten gett rin inking about groupings features, stead Order of priovity, most to least Cf ordering each and every feature

separately with numbers tke 8 or 26 or

42 You're trying to get the customer to

‘decide what is most important, but not

I {get too hung themselves Also, powers often allow up onthe exact numbers

important to the customer 1

you to occasionally spect, say, a 25 for a particular feature when you add tats 13 days ‘ something in later, and need to squeeze

QQ tesa, tnen maybe we can leave it out righ?)

oa eae <own othe customer's most important features The goa here isto piottzo,

not figure out any ofthese features aren't important So a 50 just says it can come later, not that t's nt important to

al

ˆ_ Agtronanf amamt 15 days |B te customer

¬

“rit: View “Space Miles” A: Assign a priority of 60 to those

account [BE atts fornon, 0 they dont get ize in ‘uth your Milestone 10 features,

3 na tne customer does a this

wort?

A: Yorn rep ot aati maybe mentoring dependencies

between some ofthe user stores But the tinal decision on prnbes is aways the customer’ to make

Trang 20

‘Now that you have your user stories for Milestone 1.0 in priority order, it's time to build some iterations Lay out the user stories so they make iterations that make E€RCÌS6 senso to you Be sure and write down the total days of work, and how long that

will take for your team of three developers, First one added

Trang 21

milestone = paid, iteration = on track

Fireside Chats

ae

Milestone:

Hello there, iteration, seems like its only been a

month since I saw you last

So how are things going on the project? Its

like you're always showing up, and T just

the big finish Actually, what's your purpose?

Naive? Look, just hecause I've had a few customer

run-ins before doesn’t mean I'm not important

‘mean, without me, you wouldn't have software at all

Jetalone get paid! Besides, just because Pe shown

‘up and surprised the occasional customer from time

to time

Tused to try that, too, Pd try andl soften the blow by

explaining to the customer that all of their problems

would be fixed in the next yersion of the software,

Fut that wasn't what they wanted to hear Lats of

yelling, and 1A slink off, ready to go back to work

fora year or so, and see if the customer liked me

"To make sure things go great, of course, ‘That's my job really, to make sure that every step of the way finm day 1 to day 90, the project stays on track

‘What, you thought you could just show up three

‘months into the project and everything would be just like the customer wants it? A bit naive, aren't you?

‘Oh, really sympathize with you there, [hate it

‘when the customer isn't happy with me But then again, there's 2 lot things, I mean,

\we get fogether, you know, me and the customer at once a month And, if thingy are bad, I just let the customer know it'll be better next time

Trang 22

Yel, Fry co be, bút son just how long

it takes, although T just love seeing the customer

more often Atleast once a quarter seems to line up

with their billing eycles And not so long that I get

forgotten about; there’s nothing worse than that

Are you kidding? You're not even an alpha or a

beta just some code glued together, probably an

excuse for everyone to Wear jeans to work and drink

beer on Friday afternoon,

Ha! Where would I be? Same place Tam right now,

getting ready to show the customer some real

Yeah, nobody forgets about me Around every

month, there Tam, showing up, putting on a song

and dance, pleasing the eustomer Really, Ï can

imagine how you ever got by without me,

Oh, i's tle more than that, don’t you think? Where would you be without me paving the way, making sure we're on track, handling changes and new features, and even removing existing features that aren't needed any more

Sure thing, and since T do my job, Pn sure you'll

‘work just fine Pm outta here, plenty of work lel wo

be done

youarehere+ 83

Trang 23

continuously buildable and runinable

Your answers could be

‘Your job was to lay out the user stories so they make iterations that make sense Here's what we came up with note that all our iterations are within one sure you went in different, but make

wie Manage special | mer Book ashottle | rwe Pavwith Visa/ | view Shuttle

offers MC/Payéal Mab

et: B days ee IF dap ean 15 das mm

What do you think you should do at the

end of an iteration? cho, the customer and get their feedback

util Ghestions —— Keep your software continuously sáetansealen maleemtwe —_ | building and your software

acting 3 Shei easionert always runnable so you can

A soy i cs em a not have something to show the customer iif no user stories were always get feedback from the

completes during te ieraton youve managed to do tis then yor | customer at the end of an

projects out of conrl and you need to get things back ontrack as S2 ất

84 Chapter3

Trang 24

Herations should be short and sweet

30-day iterations, with different size iterations,

and focused

Vou are here » 86

Ngày đăng: 13/08/2014, 08:20

TỪ KHÓA LIÊN QUAN