1 / 42

The Agile Alternative

The Agile Alternative. Carl Erickson, PhD Atomic Object LLC. active, acute, alert, athletic, brisk, buoyant, bustling, clever, deft, dexterous, easy-moving, energetic, fleet, frisky, limber, lithe, lively, mercurial, prompt, quick, quick-witted,

Download Presentation

The Agile Alternative

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Agile Alternative Carl Erickson, PhD Atomic Object LLC

  2. active, acute, alert, athletic, brisk, buoyant, bustling, clever, deft, dexterous, easy-moving, energetic, fleet, frisky, limber, lithe, lively, mercurial, prompt, quick, quick-witted, rapid, ready, sharp, spirited, sportive, sprightly, spry, stirring, supple, swift, vigorous, vivacious, winged, zippy brittle, clumsy, oafish, ponderous, stiff

  3. World-class software development process • Instead of particular domain or technology • Publications, diverse customer base • How we do it • Be the best place in Grand Rapids for software developers to work • Partner effectively with our customer’s staff • Facts • Spring 2000 • 13 full-time software journey and craftspeople • 3 part-time apprentices

  4. State of our industry 2004 Standish Group study 30% total failure, cancelled 50% over budget 90% late Chaos report, 1994 31% cancelled 53% more than 2x over budget

  5. Status quo "Our challenge is to get our software to the point that people expect it to work instead of expecting it to fail." Jim Larus, leader of software quality project at Microsoft Research MIT Technology Review, April 2003

  6. The price we pay NIST - industry losses $60 billion a year Doesn’t even count… government education home loss of life Therac-25 Denver Airport Ariane 5 USS Yorktown FBI Virtual Case File

  7. Successful software projects Paid for itself per the business needs (ROI) Met important deadlines Produced software that satisfies end users is stable and reliable performs acceptably is extensible and maintainable Left developers and managers happy

  8. To the rescue?

  9. Scientific Management "In the past the man has been first; in the future the system must be first.” Frederick Taylor

  10. Page 2 "I believe in this concept, but the implementation described above is risky and invites failure.” Winston Royce “Managing the Development of Large Software Systems” IEEE WESCON, August 1970

  11. (Ron Jeffries inspired these graphs) Waterfall according to plan Nirvana requirements features functionality infrastructure time

  12. Waterfall reality requirements Death March features functionality infrastructure time

  13. Agile Alternative • Learn enough to start • Work together in the same space • Express solution in features • Maintain working system, fully tested, ready to ship • Deliver features consistently • Evolve the design as you learn

  14. Agile as planned ? requirements features features infrastructure time

  15. Data-driven Projects How do you know the state of a project? How can you predict delivery date? How well does a project cope with change?

  16. Infrastructure first

  17. Features first

  18. Measure and Predict

  19. Data-driven projects

  20. Making adjustments requirements features features infrastructure time

  21. Extreme Programming? 2am, marathon, Cheetos, hacking, greasy, undocumented, brilliant, tests?, mysterious, Jolt Cola, protective, ad-hoc, brittle, cubicle, fear change, cowboy, overly elegant, code ego, real soon now, stress difficult to talk to

  22. 8-5, teamwork, code reviews, communication, coding standards, snacks, communal code tests, tests, tests, maintainable, documented predictable, copes with change Extreme Programming! 2am, marathon, Cheetos, hacking, greasy, undocumented, brilliant, tests?, mysterious, Jolt Cola, protective, ad-hoc, brittle, cubicle, fear change, cowboy, overly elegant, code ego, real soon now, stress difficult to talk to

  23. Ron Jeffries, XProgramming.com XP Practices

  24. Core of XP Story-driven dev Test-driven dev One-big-room, pairing Continuously working system

  25. Test-Driven Development White box, by the developers, concurrently Much more than finding bugs • JIT specification of a class/method • Useful documentation • Means towards improved design • Knowing when you’re done • Improving morale, feeling confident

  26. TDD Loop • Write a test, run it, watch it fail. • Write the simplest possible code to pass the test. • Run it, watch it pass, refactor as necessary. (Automation is necessary, not very difficult.)

  27. xUnit main loop suite(); suiteSetUp(); for (each test method X) { testObj = new TestClass(); testObj.setUp(); testObj.X(); testObj.tearDown(); } suiteTearDown();

  28. public void testConstructor() throws Exception { WheelData wD = new WheelData(); assertNotNull("dataLabels not initialized", wD.dataLabels); assertEquals("wrong size", 0, wD.dataLabels.size()); } // throttle starts at 0.0, runs at 10Hz void ThrottleOverTime::testRampUp() { float target = 20.0; ThrottleOverTime testObj(mock_throttle, target, 5.0); testObj.createAndRun(); CPPUNIT_ASSERT_EQUAL(target, testObj.position()); CPPUNIT_ASSERT_EQUAL(51, mock_throttle->moveCalled); }

  29. Design for testability

  30. Easier test, better design

  31. TDD Impact 10x

  32. One Big Room & Pairs

  33. Day in the Office

  34. Pair programming Two people, one computer roles: driver, navigator Produces better software Huge reducer of risk Spreads knowledge and expertise avoid single point of expertise great for training/mentoring

  35. Pair programming studies Laurie Williams, NC State University Pairs solve problems faster (wall clock time) Code produced is simpler, better Overhead (person hours) is around 20% My observations Getting stuck less often Becoming distracted (“pair pressure”) Challenged by another POV Following good practices Higher morale (more fun)

  36. Continuous IntegrationContinuously Working System • Binary status Done, not started • Breaking the build Finding bugs faster Big bang problems • Change in business Budgets Priorities Scope • Feedback Clients Users

  37. Adopting Agile • Do so with agility • Know you’ll need to adapt • Find a supportive customer • Find a coach to help

More Related