Software Development Cross Solution - Index of - Free

More documents

Recommendations

Info

factor in confidence Your team’s gut feeling matters One quick way that you can add some qualitative feedback into your bug fix estimate is by factoring in the confidence of your team. During the spike test week, you’ve all have seen the Mercury Meals code, probably in some depth, so now’s the time to run your fix rate past your team to factor in their confidence in that number. Feed confidence into your estimate Take the average of your team’s confidence, in this case 70%, and factor that into your estimate to give you some wiggle room: 404 Chapter 11 Looks pretty reasonable to me. I’d say I’m 80% confident that it will take seven days to fix the rest of the bugs. 0.8 X 13 Hmm, I’ve dug through the code more than anyone else, so I’d say I’m about 60% confident in that number... - 4 X I’d split the different, about 70% confident in the seven-day estimate. 1 70% = 10 days Download at WoweBook.Com (80% + 60% + 70%) 3 The estimate for your customer to fix the remaining bugs
Q: How many people should be involved in a spike test? A: Ideally you’d get everyone that you think will be involved in the actual bug fixing involved in the spike test. This means that you not only get a more accurate estimate, because the actual people who will finish off the bug fixing will be involved in the future estimated fixing task, but those individuals also have a week to get familiar with the code. This especially helps when you ask those members of your team to assess their confidence in the estimate that comes out of your spike test. They’ll have seen the code base and have a feel for how big all the problems might have been, so their gut feeling is worth that much more. Q: How do I pick the right tests to be part of the spike testing when I have thousands of tests failing?! A: Try to pick a random sampling, but with an eye towards getting a selection of bugs that vary in difficulty. So what you’re looking for first is a random sample, but then you want to make sure that you have a cross-section of bugs that, at a glance, at least appear to be challenging and not just the easiest things to fix. Q: I thought in test-driven development, we fixed each test as we came across it. Are we not using TDD anymore? A: This is still TDD, for sure. But this is about existing code, not writing tests for new code. You don’t want to stop and try to fix each test just yet. We need a big picture view of the code right now. However, this does cause a problem if you’re using CI, and your build fails when a test fails. In that case, after you get a count of failing tests it might make sense to cheat a little and comment out the failing tests. Then add them back in one at a time. This is risky, and might get you on the TDD Most Wanted list in no time flat, but practically speaking you might want to consider it. The most important thing is you get all of those tests passing, and nothing’s left commented out. Q: Why did we add in that confidence factor again? A: Factoring in confidence gives you that qualitative input into your estimates where your team gets a chance to say how difficult they feel the rest of the bugs may be to fix. You can take this pretty far, by playing planning poker with your bugs, but remember that the longer you spend assessing confidence, the less time you have to actually fix the bugs. It’s always a compromise between getting an absolute estimate for how long it will take to fix the bugs (and this can really only be obtained by actually fixing them all) and getting a good enough feel for how fast you can squash bugs and getting that estimate to your customer. Q: Why five days for a spike test? A: Good question. Five days is a good length because it focuses your team on just the spike test for a week (rather than attempting to multitask during that week), and it gives everyone enough time to do some serious bug fixing. Q: Can I use a shorter length? Download at WoweBook.Com bugs A: You can, but this will affect how many bugs your team can work through, and that affects your confidence in your final estimate. In the worst case scenario, no bugs at all are fixed in your spike test, and you’re left confused and without a real end in sight. Five days is enough time for some serious bugs to be fixed and for you to be able to come out of the spike test with some confidence in your estimate for fixing the remainder of the bugs. And in the best case scenario, you come out of the spike test week with no bugs at all! Q: So should I do this on code we’ve developed, too? A: You really shouldn’t need to. First of all, you shouldn’t have a massive stack of failing tests. If a test is failing, the build should be failing, and you should fix things immediately. And with bugs, they should be prioritized in with your other work, so it’s unlikely you’ll suddenly get a giant stack of bugs you need to sort through. And finally, you and your team should know your code base pretty well. Your coverage reports provide value, and you know there can’t be too much code involved in any given bug. Q: How can I be absolutely sure that, even when I’ve factored in my team’s confidence, that 10 days is definitely enough to fix all these bugs? A: You can’t. Ten days is still just an estimate, and so it’s how long you think it will take, based on your spike test and your team’s gut feelings. You’ve done everything you can to be confident in your estimate, but it is still just an estimate. When it comes to bugs, you need to be aware that there is a risk that your estimates will be wrong, and that’s a message that you need to convey to your customer too... you are here 4 405
Page 2 and 3:
Download at WoweBook.Com
Page 4 and 5:
Praise for Head First Object-Orient
Page 6 and 7:
Other related books from O’Reilly
Page 8 and 9:
Head First Software Development by
Page 10 and 11:
the authors Author(s) of Head First
Page 12 and 13:
table of contents x 1 If The Goal g
Page 14 and 15:
table of contents xii 3 project pla
Page 16 and 17:
table of contents xiv 5 good-enough
Page 18 and 19:
table of contents xvi 6 / It buildi
Page 20 and 21:
table of contents xviii 8 Sometimes
Page 22 and 23:
table of contents xx 10 Think the n
Page 24 and 25:
table of contents xxii 12 You’ve
Page 26 and 27:
table of contents xxiv ii appendix
Page 28 and 29:
how to use this book Who is this bo
Page 30 and 31:
how to use this book xxviii intro W
Page 32 and 33:
how to use this book Here’s what
Page 34 and 35:
how to use this book Read Me This i
Page 36 and 37:
the review team The technical revie
Page 38 and 39:
safari books online Safari® Books
Page 40 and 41:
Tom’s Trails Tom’s Trails is go
Page 42 and 43:
the Big Bang approach The Big Bang
Page 44 and 45:
the Big Bang ends with a big mess B
Page 46 and 47:
great software development is... 8
Page 48 and 49:
delivering with iteration Getting t
Page 50 and 51:
an iteration delivers working softw
Page 52 and 53:
an iteration is a complete developm
Page 54 and 55:
uild a plan out of iterations and f
Page 56 and 57:
deciding on a iteration tempo for y
Page 58 and 59:
change happens The customer WILL ch
Page 60 and 61:
handle change with iteration Iterat
Page 62 and 63:
use the right process for you The r
Page 64 and 65:
CHAPTER 1 your software development
Page 66 and 67:
exercise solutions 28 Chapter 1 1 P
Page 68 and 69:
orion’s orbits Orion’s Orbits i
Page 70 and 71:
equirements start with customer ide
Page 72 and 73:
capturing what’s in your customer
Page 74 and 75:
getting more with role playing and
Page 76 and 77:
customer-oriented requirements Our
Page 78 and 79:
keep your customer in the loop Q: W
Page 80 and 81:
user stories capture what your soft
Page 82 and 83:
estimates come with assumptions 44
Page 84 and 85:
assumptions kill confidence in your
Page 86 and 87:
highlighting assumptions and obtain
Page 88 and 89:
assumptions are killed or become ri
Page 90 and 91:
use your customer effectively 52 Ch
Page 92 and 93:
keep estimates small A BIG user sto
Page 94 and 95:
aim for estimates you and your team
Page 96 and 97:
your estimates are your promise Q:
Page 98 and 99:
develop your estimates cyclically T
Page 100 and 101:
sum your estimates to find out your
Page 102 and 103:
when your project is too long 64 Ch
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
deliver what you can, when it’s n
Page 110 and 111:
priorities come from your customer
Page 112 and 113:
Title: Description: Est: Title: 15
Page 114 and 115:
factoring in team performance 76 Ch
Page 116 and 117:
uilding achievable milestones Work
Page 118 and 119:
your customer decides priority Titl
Page 120 and 121:
milestone = paid, iteration = on tr
Page 122 and 123:
continuously buildable and runnable
Page 124 and 125:
inging reality to your plan 86 Chap
Page 126 and 127:
velocity applies your real performa
Page 128 and 129:
from ideal to real estimates Progra
Page 130 and 131:
confidence comes at a price When is
Page 132 and 133:
iterations with velocity The maximu
Page 134 and 135:
eality means being honest Title: Es
Page 136 and 137:
eaking realistic but bad news Manag
Page 138 and 139:
introducing the big board The Big B
Page 140 and 141:
happiness is a project that can be
Page 142 and 143:
performance and burn down Work left
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
introducing iSwoon Introducing iSwo
Page 150 and 151:
eak up user stories into tasks Task
Page 152 and 153:
tasks have estimates Your task desc
Page 154 and 155:
tasks on your board Add your tasks
Page 156 and 157:
moving tasks to in progress Start w
Page 158 and 159:
multiple tasks at the same time Wha
Page 160 and 161:
keep communication flowing with dai
Page 162 and 163:
doing your first task Task 1: Creat
Page 164 and 165:
inging your design to life with a s
Page 166 and 167:
exercise solution The date is asked
Page 168 and 169:
monitoring your progress Standup me
Page 170 and 171:
updating your project board 132 Cha
Page 172 and 173:
updating your project board 134 Cha
Page 174 and 175:
into the second week Standup meetin
Page 176 and 177:
detecting problems with the design
Page 178 and 179:
surprises... 140 Chapter 4 We inter
Page 180 and 181:
dealing with unplanned tasks If the
Page 182 and 183:
velocity doesn’t account for surp
Page 184 and 185:
you know where you are We have a lo
Page 186 and 187:
meet velocity Head First: Welcome,
Page 188 and 189:
inging iSwoon under control iSwoon
Page 190 and 191:
detecting bad design ...you needed
Page 192 and 193:
design refactoring The Date class c
Page 194 and 195:
srp analysis Spotting multiple resp
Page 196 and 197:
single responsibility It makes sens
Page 198 and 199:
don’t repeat yourself Your design
Page 200 and 201:
efactoring iSwoon’s design A date
Page 202 and 203:
standup meeting The post-refactorin
Page 204 and 205:
unplanned work Unplanned tasks are
Page 206 and 207:
good-enough delivers “Good Enough
Page 208 and 209:
end of iteration board When everyth
Page 210 and 211:
exercises 172 Chapter 5 Take each o
Page 212 and 213:
exercise solutions Unplanned tasks
Page 214 and 215:
Page 216 and 217:
introducing beatbox pro You’ve go
Page 218 and 219:
digging into code Here’s the code
Page 220 and 221:
finish the story And now the GUI wo
Page 222 and 223:
merging changes And Bob does the sa
Page 224 and 225:
disaster recovery What went wrong?
Page 226 and 227:
version control in action Let’s s
Page 228 and 229:
1 2 creating a repository First set
Page 230 and 231:
merging changes Most version contro
Page 232 and 233:
identifying conflicts If your softw
Page 234 and 235:
esolving conflicts Make these chang
Page 236 and 237:
dealing with older code More iterat
Page 238 and 239:
dealing with multiple releases We h
Page 240 and 241:
viewing logs Good commit messages m
Page 242 and 243:
tagging revisions (Emergency) stand
Page 244 and 245:
anches and tags 1 Use the mkdir com
Page 246 and 247:
working with branches Fixing Versio
Page 248 and 249:
anches, tags, and subversion Q: I
Page 250 and 251:
avoiding unnecessary branches When
Page 252 and 253:
214 Chapter 6 What version control
Page 254 and 255:
CHAPTER 6 Development Techniques Us
Page 256 and 257:
Page 258 and 259:
uilding buildable software Develope
Page 260 and 261:
introducing ant Ant: a build tool f
Page 262 and 263:
more exercises 224 Chapter 6 ½ Are
Page 264 and 265:
a full build script The javac task
Page 266 and 267:
habits of good build scripts Good b
Page 268 and 269:
even more build script tricks Good
Page 270 and 271:
version control your build script Y
Page 272 and 273:
CHAPTER 6 1/2 Development Technique
Page 274 and 275:
it never rains but it pours Things
Page 276 and 277:
lack box testing There are three wa
Page 278 and 279:
grey box testing Grey-box testing g
Page 280 and 281:
white box testing was Below is a us
Page 282 and 283:
testing functionality BeatB These s
Page 284 and 285:
you create tests test for establish
Page 286 and 287:
one-click testing Testing EVERYTHIN
Page 288 and 289:
making the most of a framework Auto
Page 290 and 291:
continuous integration For you and
Page 292 and 293:
setting up continuous integration A
Page 294 and 295:
tests only cover what you tell them
Page 296 and 297:
tested code is completed code } 258
Page 298 and 299:
putting code to the test 260 Chapte
Page 300 and 301:
100% coverage All three of these te
Page 302 and 303:
using a coverage report Testing all
Page 304 and 305:
the cost of testing Q: How do cover
Page 306 and 307:
is 100% coverage efficient? 268 Cha
Page 308 and 309:
an environment for testing 270 Chap
Page 310 and 311:
exercise solutions 272 Chapter 7 Te
Page 312 and 313:
Page 314 and 315:
test before code Test FIRST, not la
Page 316 and 317:
unit testing Your first test... The
Page 318 and 319:
green means pass Get your tests to
Page 320 and 321:
testing a user story’s functional
Page 322 and 323:
implement a test in code import org
Page 324 and 325:
drive your code with TDD In TDD, te
Page 326 and 327:
task done when tests pass Completin
Page 328 and 329:
first fail Red: write (failing) tes
Page 330 and 331:
keep it simple You can just make up
Page 332 and 333:
simple code is testable code Always
Page 334 and 335:
switching to test code with the str
Page 336 and 337:
where to place your test code Remem
Page 338 and 339:
etter code through testing Testing
Page 340 and 341:
tests = code and lots of it More te
Page 342 and 343:
mock objects We need lots of differ
Page 344 and 345:
using a mock object framework Mock
Page 346 and 347:
why mock objects? Q: These mock obj
Page 348 and 349:
all green, you’re done It’s not
Page 350 and 351:
test, red, code, green A day in the
Page 352 and 353:
Page 354 and 355:
Page 356 and 357:
esults from an iteration Your itera
Page 358 and 359:
daily standup meetings Standup Meet
Page 360 and 361:
urn-down analysis 322 Chapter 9 Bef
Page 362 and 363:
system testing System testing MUST
Page 364 and 365:
incorporating system testing System
Page 366 and 367:
issues with test iterations More it
Page 368 and 369:
enabling communication 330 Chapter
Page 370 and 371:
This is usually called acceptance t
Page 372 and 373:
filing and fixing a bug The life (a
Page 374 and 375:
ug trackers So you found a bug....
Page 376 and 377:
learn from your iteration But there
Page 378 and 379:
different project hurdles 340 Chapt
Page 380 and 381:
iteration reviews Time for the iter
Page 382 and 383:
other things to do A GENERAL priori
Page 384 and 385:
CHAPTER 9 346 Chapter 9 Tools for y
Page 386 and 387:
crossword solution 13 B 1 S Iterati
Page 388 and 389:
an iteration finishes with more tha
Page 390 and 391:
planning the next iteration You nee
Page 392 and 393: uilding your board for the next ite
Page 394 and 395: uilding your board for the next ite
Page 396 and 397: factoring in real velocity Q: A tea
Page 398 and 399: the customer still rules And it’s
Page 400 and 401: it’s still software Someone else
Page 402 and 403: integration tasks on your board Tit
Page 404 and 405: integrating third-party code How yo
Page 406 and 407: euse means trust too //... 368 Chap
Page 408 and 409: when reuse lets you down Testing yo
Page 410 and 411: trust no one Standup meeting 372 Ch
Page 412 and 413: looking for problems in reused sour
Page 414 and 415: finding problems in reused source c
Page 416 and 417: your process deals with it You with
Page 418 and 419: oken code happens � � � � Q
Page 420 and 421: exercise solutions 2 R 1 R 3 E S P
Page 422 and 423: At the end of the last chapter, thi
Page 424 and 425: always communicate First, you’ve
Page 426 and 427: prioritize what you do 388 Chapter
Page 428 and 429: ump some things for later 390 Chapt
Page 430 and 431: apply your process Priority one: ge
Page 432 and 433: focus on functionality We could fix
Page 434 and 435: test for bugs Figure out what funct
Page 436 and 437: think about estimating Even though
Page 438 and 439: spike tests Spike test to estimate
Page 440 and 441: estimate what’s left What do the
Page 444 and 445: always communicate Give your custom
Page 446 and 447: apply other techniques Figure out w
Page 448 and 449: successful deliveries matter Things
Page 450 and 451: functionality wins most importantly
Page 452 and 453: CHAPTER 11 414 Chapter 11 Tools for
Page 454 and 455: crossword solution 10 F 15 H 5 P Bu
Page 456 and 457: software process defined Pinning do
Page 458 and 459: evaluate everything The big board 4
Page 460 and 461: ensure changes improve things The b
Page 462 and 463: formalize if necessary Formal attir
Page 464 and 465: other resources Some additional res
Page 466 and 467: CHAPTER 12 428 Chapter 12 Tools for
Page 468 and 469: exercise solutions 4 S 11 P 14 A So
Page 470 and 471: Download at WoweBook.Com
Page 472 and 473: uml and class diagrams #1. UML clas
Page 474 and 475: sequence diagrams #2. Sequence diag
Page 476 and 477: user stories and use cases #3. User
Page 478 and 479: system testing vs. unit testing #4.
Page 482 and 483: CHAPTER 1 development techniques CH
Page 484 and 485: development principles Deliver soft
Page 488 and 489: the index building projects (contin
Page 490 and 491: the index H Head First Java BeatBox
Page 492 and 493:
the index No Dumb Questions (contin
Page 494 and 495:
the index singularly focused 152 so
Page 496 and 497:
the index third-party code bugs in
show all

Software Development Cross Solution - Index of - Free

Create successful ePaper yourself

Delete template?

Save as template?