Loading ...
Sorry, an error occurred while loading the content.

RE: Agile is not always the right option

Expand Messages
  • Vlietstra, Joe (ES)
    On Wed Oct 13 George Dinwiddie lists@idiacomputing.com gdinwiddie ... http://agilemanifesto.org/principles.html ... OK, I ve followed this thread and
    Message 1 of 95 , Oct 14, 2010
    • 0 Attachment
      On Wed Oct 13 "George Dinwiddie" lists@... gdinwiddie
      wrote:
      > ...
      > Which of the 12 principles at
      http://agilemanifesto.org/principles.html
      > do you find not generally applicable?

      OK, I've followed this thread and resisted jumping in until now.
      In our area (embedded spacecraft software), we run into difficulties
      with:
      -- Welcome changing requirements, even late in development...
      -- Deliver working software frequently...

      Time window in which 100% agile development makes sense is bracketed by:
      -- Availability of hardware
      Hardware is not usually available in the early part of the project.
      We usually spend this time working on requirements and design simply
      because we can't develop code. Although it's possible to code/test
      on a simulated platform, this hasn't worked out well in practice
      since most of the "interesting" development is for new hardware.
      -- System test
      At this point the flight software is a small piece of a very
      expensive
      system and no one "appreciates" frequent software builds. As launch
      date approaches, flight software updates affects hundreds of people;
      after launch, flight software updates are "once per career".
    • James Grenning
      ... hey if your requirements do not change, cool. Does your understand of them change? Does your knowledge of the solution change? ... In an embedded context,
      Message 95 of 95 , Oct 17, 2010
      • 0 Attachment
        On Oct 14, 2010, at 11:19 AM, Vlietstra, Joe (ES) wrote:

        > > Which of the 12 principles at
        > http://agilemanifesto.org/principles.html
        > > do you find not generally applicable?
        >
        > OK, I've followed this thread and resisted jumping in until now.
        > In our area (embedded spacecraft software), we run into difficulties
        > with:
        > -- Welcome changing requirements, even late in development...
        >
        hey if your requirements do not change, cool. Does your understand of them change? Does your knowledge of the solution change?
        > -- Deliver working software frequently...
        >
        In an embedded context, I like to think of this one as regular visible progress. Not just documents that say how the code/system is expected to work and may be designed, but working slices of functionality backed by automated test to keep them working.

        >
        > Time window in which 100% agile development makes sense is bracketed by:
        > -- Availability of hardware
        > Hardware is not usually available in the early part of the project.
        > We usually spend this time working on requirements and design simply
        > because we can't develop code.
        >
        When I first saw TDD in Extreme Programming back in 1999 I immediately saw it as a part of the solution to the "we don't have hardware" problem.
        You can choose to dual target your code, making sure that certain code is independent of the hardware. This lets many unit tests and story tests run off the target platform. When you finally get your target hardware, you know that much of the code behaves per your tests off the target. You can then run them in the target as well.

        This approach also encourages better design by managing the dependency on the target hardware

        There is more to the target hardware bottle neck than just no hardware at the beginning of a development effort. You also have to deal with
        hardware that has defects
        long edit, build, load and test cycles
        scarse hardware that everyone needs



        When and if you have a target, you can also run tests on the target. Differences in execution and portability problems come to the surface.
        > Although it's possible to code/test
        > on a simulated platform, this hasn't worked out well in practice
        > since most of the "interesting" development is for new hardware.
        >
        BTW: using TDD for embedded does not mean you need a simulated platform. Using stubs, fakes and mocks allow unit tests, as well as higher level tests.


        > -- System test
        > At this point the flight software is a small piece of a very
        > expensive
        > system and no one "appreciates" frequent software builds. As launch
        > date approaches, flight software updates affects hundreds of people;
        > after launch, flight software updates are "once per career".
        >
        >
        The fact that you have a very expensive system is one of the reasons that it is really important to assure your code does what you think (the point of unit tests). testing to prevent defects seems that it would be very important to keep from losing systems where there is no air.

        The idea behind continuous integration is that if something is difficult, you should do it more often. Wait a long time to integrate, and integration will be a big issue getting more and more difficult. Integrate frequently and integration issues will be smaller though you will have more of them. You have a chance of applying continuous Improvement.

        In embedded development frequent builds likely do not usually lead to early releases. That does not negate the value of them. They provide concrete progress. They offer early opportunities for integration.

        I'd like to learn more about how you protect your career.

        James
        --------------------------------------------------------------------------------------------
        James Grenning TDD for Embedded C is in Beta
        www.renaissancesoftware.net http://pragprog.com/titles/jgade/
        www.renaissancesoftware.net/blog
        www.twitter.com/jwgrenning



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.