Downloaded 24 times
![[exec] Result: PASS
[echo]
[echo] mrtim
[exec] # ./t/4154.test
[exec] # ./t/4160.test
[exec] # ./t/4163.test
[exec] # ./t/4175.test
[exec] # ./t/4176.test
[exec] # ./t/core01.test
[exec] # ./t/opt01.test
[exec] # ./t/pod01.test
[exec] ./t/test.t .. ok
[exec] All tests successful.
[exec] Files=1, Tests=14, 29 wallclock secs ( 0.02 usr 0.00 sys + 26.73 cusr 3.22 csys = 29.97 CPU)
[exec] Result: PASS
[echo]
[echo] mrtimfix
[exec] # ./t/opt01.test
[exec] ./t/test.t .. ok
[exec] All tests successful.
[exec] Files=1, Tests=7, 6 wallclock secs ( 0.02 usr 0.00 sys + 4.52 cusr 0.56 csys = 5.10 CPU)
[exec] Result: PASS
[echo]
[echo] mrcallrm
[exec] # ./t/4119.test
[exec] # ./t/4137.test
[exec] # ./t/4138.test
[exec] # ./t/4139.test
[exec] # ./t/pod01.test
[exec] ./t/test.t .. ok
[exec] All tests successful.
[exec] Files=1, Tests=11, 5 wallclock secs ( 0.02 usr 0.00 sys + 4.28 cusr 0.54 csys = 4.84 CPU)
[exec] Result: PASS
BUILD SUCCESSFUL
Total time: 3 minutes 20 seconds
37](https://image.slidesharecdn.com/1-mycaseforagile-slides-111020165115-phpapp02/85/My-Case-for-Agile-76-320.jpg)
Uploaded byCary Millsap
My Case for Agile
Cary Millsap's presentation on agile methods discusses the importance of embracing change in software development, emphasizing that traditional methods often fell short. He outlines five key practices from Extreme Programming (XP) that enhance responsiveness and product quality. The talk also addresses challenges faced when adopting agile, such as customer collaboration issues and cultural mismatches within teams.
More Related Content
My Case for Agile
- 1.
- 2.
- 3.
- 4.
- 5. follow professional comedian yell at audience 2
- 6. follow professional comedian yell at audience 2
- 7. follow professional comedian yell at audience mandate awkward social contact with your seatmate 2
- 8. follow professional comedian yell at audience mandate awkward social contact with your seatmate 2
- 9. Cary Millsap Teaching Consulting Business Method Software 1985–1987 1988–1989 1990–1992 1993–1995 1996–1999 2000–2003 2004–2008 2009–2010 2011–201x 0 25 50 75 100 3
- 10. MeTHOD R Cary Millsap If you’d like to talk about software this week, tweet me at @CaryMillsap 4
- 11. 1. Agile and me 2. Five practices from XP 3.How Agile has helped me 4. What has not worked 5. Discussion 5
- 12.
- 13. Agile as a joke... 7 Photo: http://www.sxc.hu/browse.phtml?f=view&id=1174739
- 14. DBAs Developers 8
- 15.
- 16. DBAs Developers 10
- 17. DBAs Developers 11
- 18. Why Agile? Embrace change. —Kent Beck 12
- 19. 1 Realization Change is unpredictable, inevitable, multidimension al, comple x, ... 13
- 20. 2 Realization Responsiveness to change is an advantage. 14
- 21. 3 Realization Traditional design‐build methods were not working for me. 15
- 22.
- 23.
- 24.
- 25. Developers 18
- 26. Believers of Developers agile values and principles 18
- 27. Believers of Developers agile values and principles Disciplined agile practitioners 18
- 28.
- 29. Everyone 19
- 30. Everyone Says X 19
- 31. Everyone Says X Does X 19
- 32. a) Satisfy the customer through early and continuous delivery of valuable software. b) Working software is the primary measure of progress. 20
- 33.
- 34. Manufacturing = Database Application optimization optimization 21
- 35. Manufacturing = Database Application = Software Development optimization optimization optimization 21
- 36. Manufacturing = Database Application = Software Development = Baseball Club optimization optimization optimization optimization 21
- 37. Manufacturing = Database Application = Software Development = Baseball Club optimization optimization optimization optimization Global goal: maximize... ❶ net profit ❷ cash flow ❸ return on investment 21
- 38.
- 39. Agile? Why 22
- 40. Why Agile? ✓ better ❶ net profit ❷ cash flow ❸ return on investment 22
- 41. Why Agile? ✓ better ❶ net profit ❷ cash flow ❸ return on investment ✓ higher quality 22
- 42. Why Agile? ✓ better ❶ net profit ❷ cash flow ❸ return on investment ✓ higher quality ✓ more fulfillment 22
- 43. Why Agile? ✓ better ❶ net profit ❷ cash flow ❸ return on investment ✓ higher quality ✓ more fulfillment ✓ more enjoyment 22
- 44. Why Agile? ✓ better ❶ net profit ❷ cash flow ❸ return on investment ✓ higher quality ✓ more fulfillment ✓ more enjoyment Not because it’s easy. 22
- 45. Why Agile? ✓ better ❶ net profit ❷ cash flow ❸ return on investment ✓ higher quality ✓ more fulfillment ✓ more enjoyment Not because it’s easy. It’s not. 22
- 46.
- 47. Incremental Design The question is not whether or not to design, the question is when to design. Incremental design suggests that the most effective time to design is in the light of experience. —Kent Beck 24
- 48. Plans fail. There are ways to prevent a failed plan from failing your project. 25
- 49.
- 50.
- 51.
- 52. Big Design Up Front 26
- 53. Big Design Up Front Increment al Design 26
- 54. Rapid Iteration Working software is the primary measure of progress. —Kent Beck 27
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62. Test‐First Programming Continuous testing reduces the time to fix errors by reducing the time to discover them. —Kent Beck 30
- 63.
- 64.
- 65.
- 66.
- 67.
- 68. How Test‐First Programming works: 1. Add a case 2. Add a test 3.Run all tests (✔✔✔✔✗ ...new test fails) 32
- 69. How Test‐First Programming works: 1. Add a case 2. Add a test 3.Run all tests (✔✔✔✔✗ ...new test fails) 4. Write code 32
- 70. How Test‐First Programming works: 1. Add a case 2. Add a test 3.Run all tests (✔✔✔✔✗ ...new test fails) 4. Write code 5. Run all tests (✔✔✔✔✔ ...all tests succeed) 32
- 71. How Test‐First Programming works: 1. Add a case 2. Add a test 3.Run all tests (✔✔✔✔✗ ...new test fails) 4. Write code 5. Run all tests (✔✔✔✔✔ ...all tests succeed) 6. Refactor 32
- 72. Pair Programming Silence is the sound of risk piling up. —Kent Beck 33
- 73.
- 74. Programmer Wingman Wingman (option 1) (option 2) Wingman (option 3) 35
- 75. Ten‐Minute Build Practices should lower stress. An automated build becomes a stress reliever at crunch time. “Did we make a mistake? Let’s just build and see.” —Kent Beck 36
- 76. [exec] Result: PASS [echo] [echo] mrtim [exec] # ./t/4154.test [exec] # ./t/4160.test [exec] # ./t/4163.test [exec] # ./t/4175.test [exec] # ./t/4176.test [exec] # ./t/core01.test [exec] # ./t/opt01.test [exec] # ./t/pod01.test [exec] ./t/test.t .. ok [exec] All tests successful. [exec] Files=1, Tests=14, 29 wallclock secs ( 0.02 usr 0.00 sys + 26.73 cusr 3.22 csys = 29.97 CPU) [exec] Result: PASS [echo] [echo] mrtimfix [exec] # ./t/opt01.test [exec] ./t/test.t .. ok [exec] All tests successful. [exec] Files=1, Tests=7, 6 wallclock secs ( 0.02 usr 0.00 sys + 4.52 cusr 0.56 csys = 5.10 CPU) [exec] Result: PASS [echo] [echo] mrcallrm [exec] # ./t/4119.test [exec] # ./t/4137.test [exec] # ./t/4138.test [exec] # ./t/4139.test [exec] # ./t/pod01.test [exec] ./t/test.t .. ok [exec] All tests successful. [exec] Files=1, Tests=11, 5 wallclock secs ( 0.02 usr 0.00 sys + 4.28 cusr 0.54 csys = 4.84 CPU) [exec] Result: PASS BUILD SUCCESSFUL Total time: 3 minutes 20 seconds 37
- 77.
- 78. Big Spec == Big Mistake the testing‐is‐too‐expensive problem the antigravity problem the gluttony problem the I‐know‐it’s‐what‐I‐asked‐for‐but‐it’s‐not‐what‐I‐want problem 39
- 79. ‘‘ Maintain onlythe code and the tests as permanent artifacts. Generate other documents from the code and tests. —Kent Beck 40
- 80. Regression Testing == Awesome far less expensive than I thought makes refactoring so much easier inspires confidence makes support and documentation better 41
- 81. Incremental Design == Better Design makes decisions easier, more obvious thus less expensive and just better creates inspired innovation 42
- 82. !""# $%"& '(#" 43
- 83. Here’s what I thought I wanted when I designed big up front... time features time 44
- 84. features time Build something valuable that runs, and release it. features time 45
- 85. features time Build a little more and release, a little more and release... features time 46
- 86. features time ...and discover. features time 47
- 87. features time What I want is not what I imagined. features time 48
- 88. features features time ✓ Usable software earlier ✓ Experience informs the design ✓ Better design in the end 49
- 89. Awesome features Not features Awesome time ✓ Usable software earlier ✓ Experience informs the design ✓ Better design in the end 49
- 90.
- 91. 6 No CRACK Customer Collaborative + Representative + Authorized + Committed + Knowledgable nobody to say No, so everything is Yes Suicide! team doesn’t know what to do, makes it up as it goes along 51
- 92. 6 Too Many Customers just as bad as no customer Suicide! great design is also about No 52
- 93. 6 Cultural Mismatch agile is about decentralization of responsibility, accountability, ... centralization + agile == hypocrisy agile requires openness, honesty about where failures are 53
- 94. 6 Talent Mismatch undisciplined + agile == chaos participants must actively design, optimize key skill: project factorization to produce running, valuable software every n weeks 54
- 95.
- 96. Cary Millsap MeTHOD R http://method‐r.com http://carymillsap.blogspot.com @CaryMillsap @MethodR 56
- 97.
Editor's Notes
- #2 \n
- #3 Three things I learned in this morning’s keynote...\n
- #4 Three things I learned in this morning’s keynote...\n
- #5 Three things I learned in this morning’s keynote...\n
- #6 Three things I learned in this morning’s keynote...\n
- #7 Three things I learned in this morning’s keynote...\n
- #8 Three things I learned in this morning’s keynote...\n
- #9 \n
- #10 \n
- #11 \n
- #12 \n
- #13 “They must be doing ‘agile’ in the kitchen.”\n
- #14 I have 4 questions for you:\nHow many would be willing to show your hand?\nHow many DBAs?\nHow many developers?\nHow many both DBA and developer?\n
- #15 Crush the Castle\n
- #16 Here’s a great metaphor that Tom Kyte showed one time.\n
- #17 \n
- #18 \n
- #19 \n
- #20 \n
- #21 \n
- #22 \n
- #23 \n
- #24 \n
- #25 \n
- #26 This is where the DBAs in the room will stiffen up.\n“Change is not inevitable; it’s a consequence of not planning well enough.”\nChange is inevitable, multidimensional.\n\n
- #27 I know this from running my own business.\n
- #28 “Some long stories, I can tell you later…”\n\n
- #29 \n
- #30 Some agile practices require extraordinary discipline.\n
- #31 \n
- #32 \n
- #33 \n
- #34 \n
- #35 \n
- #36 \n
- #37 \n
- #38 \n
- #39 \n
- #40 “The more general case…”\n
- #41 “The more general case…”\n
- #42 “The more general case…”\n
- #43 “The more general case…”\n
- #44 “The more general case…”\n
- #45 “The more general case…”\n
- #46 “The more general case…”\n
- #47 “The more general case…”\n
- #48 “The more general case…”\n
- #49 \n
- #50 \n
- #51 \n
- #52 \n
- #53 \n
- #54 Said another way: “Because I think Agile optimizes software development for me.”\n...But it’s worth it.\n
- #55 Said another way: “Because I think Agile optimizes software development for me.”\n...But it’s worth it.\n
- #56 Said another way: “Because I think Agile optimizes software development for me.”\n...But it’s worth it.\n
- #57 Said another way: “Because I think Agile optimizes software development for me.”\n...But it’s worth it.\n
- #58 Said another way: “Because I think Agile optimizes software development for me.”\n...But it’s worth it.\n
- #59 Said another way: “Because I think Agile optimizes software development for me.”\n...But it’s worth it.\n
- #60 Said another way: “Because I think Agile optimizes software development for me.”\n...But it’s worth it.\n
- #61 \n
- #62 \n
- #63 \n
- #64 Top picture: attempt at optimizing (Frederick Taylor style) by separating “thinking” from “doing.”\nBut it doesn’t work when you’re inventing, which software development almost always is.\n
- #65 Top picture: attempt at optimizing (Frederick Taylor style) by separating “thinking” from “doing.”\nBut it doesn’t work when you’re inventing, which software development almost always is.\n
- #66 Top picture: attempt at optimizing (Frederick Taylor style) by separating “thinking” from “doing.”\nBut it doesn’t work when you’re inventing, which software development almost always is.\n
- #67 Top picture: attempt at optimizing (Frederick Taylor style) by separating “thinking” from “doing.”\nBut it doesn’t work when you’re inventing, which software development almost always is.\n
- #68 \n
- #69 \n
- #70 \n
- #71 These loops aren’t “design reviews,” they’re runnable software reviews.\n
- #72 These loops aren’t “design reviews,” they’re runnable software reviews.\n
- #73 These loops aren’t “design reviews,” they’re runnable software reviews.\n
- #74 \n
- #75 \n
- #76 Write code and refine tests until all tests pass.\n
- #77 Write code and refine tests until all tests pass.\n
- #78 Write code and refine tests until all tests pass.\n
- #79 Write code and refine tests until all tests pass.\n
- #80 Write code and refine tests until all tests pass.\n
- #81 Write code and refine tests until all tests pass.\n
- #82 Write code and refine tests until all tests pass.\n
- #83 \n
- #84 \n
- #85 \n
- #86 \n
- #87 \n
- #88 \n
- #89 Testing is too expensive: No normal human can test and retest to a 300-page spec.\nAntigravity: I can spec in English things that are impossible to do in code; ambiguity also a problem.\nGluttony: When you’re writing, you’re king; nothing can stop you (cost is not in focus).\nIt’s not what I want: Imagination is just no substitute for touch/use experience.\n
- #90 One of the most elemental principles behind relational design: store information once and only once.\nPrevent update anomaly.\n
- #91 \n
- #92 \n
- #93 \n
- #94 \n
- #95 \n
- #96 \n
- #97 \n
- #98 \n
- #99 \n
- #100 \n
- #101 \n
- #102 Agile principle YANGNI (you’re not going to need it): prove that you’ll need it before you build it.\n\nhttp://www.truesake.com/newsletters/2008-01.php\n
- #103 \n
- #104 \n
- #105 \n
- #106 \n
- #107 \n
- #108 \n
- #109 \n
- #110 \n
- #111 \n
- #112 \n
- #113 \n
- #114 \n
- #115 \n
- #116 \n
- #117 \n
- #118 \n
- #119 \n
- #120 \n
- #121 \n
- #122 \n
- #123 \n
- #124 \n
- #125 \n