17

I've always wondered how to apply agile methods really are in large complex embedded system software (100+ engineers). Firmware development has some unique characteristics that make it difficult to do agile (ie. Hardware is not available until late in the dev cycle; Once product is released, can't easily update firmware; etc...)

The norm in this kind of development is thick documentation and grueling peer reviews. You can't get a simple code fix like renaming a variable without 2-3 signatures. (I exaggerate a little but this is typical. Additionally, a lot of people do take shortcuts and the Project Managers even approve them especially in the face of hard market deadlines.)

I would like to hear any tips or guidelines on how to adopt agile methodology for firmware development projects.

yannis
  • 39,647
hopia
  • 311
  • 2
  • 6

4 Answers4

10

I think two techniques are key:

  • Develop a complete simulator or test-environment for the hardware, so that you can develop the software as if you have real hardware. Don't skimp or take shortcuts here: developing a good simulator will pay off.

  • Write lots of unit tests against the simulator.

Once you have these things going, and people are confident that the simulator and unit tests will give an accurate idea of how things will work with the hardware, it will be easier to adopt other agile techniques (short iterations, relentless refactoring, etc.).

Kristopher Johnson
  • 1,729
2

The impact of Agile on a development process involving multiple suppliers can be compared to what happens when a company goes JIT.

In order to deliver JIT, each of the company's suppliers has to deliver JIT.

function deliversJIT( company ) { 
    return company.isJIT() && map( deliversJIT, company.suppliers() );
}

Likewise, if you want a complex product to be developed according to Agile methodologies, every subgroup in the chain should be able to work that way.

In terms of 'incremental' development (a.k.a. Tracer Bullets of 15 years ago), this would imply that the 'core' is released really soon to the driver guy, and that the basic driver be available to the integrator, and that the GUI would be developed, beit with one single button and an edit box, at the same time.

The hard part is convincing the hardware designers, coming from a solid think-upfront engineering discipline, to join our tinkerer society.

The second hardest part is finding a way to enable incremental development in a world where a hardware print is to be ordered 3 weeks in advance. I'm thinking emulators, fpga's here. I'm not a hardware guy though.

If you are willing to drop on incremental hardware development, you can, just like on the borders of a JIT chain, foresee a buffering mechanism that allows the Agile teams to advance.

Let's not be blind: Agile does have to deal with heavy-weight processes, too! Don't ask the Agile team to now 'refactor' their Java code base to Python in the next sprint. It is only because some of the parts are really really stable that we can dance our Agile moves on top of them.

xtofl
  • 344
  • 1
  • 2
  • 10
1

Agile Manifesto: http://agilemanifesto.org/

"Individuals and interactions over processes and tools"

  • Meet more. Push paper less.

"Working software over comprehensive documentation"

  • Prototype and build technology spikes early and often.

  • Solve the user's real problem rather than continue to build fussy adherence to a specification. This means evolutionary solutions. The idea that we have to build it right because we can never built it again is wrong. Plan on iterating. Make it part of the marketing and roll-out strategy.

"Customer collaboration over contract negotiation"

  • Hyper-complex change-control processes are just ways of saying "no" to the customer.

  • Locking down all requirements up front and then imposing change control is another way of saying "no".

  • If you already plan on more than one release, then you can more easily defer requirements to a later release. Once the customer has the device with the embedded software, the next release will change in it's priorities.

"Responding to change over following a plan"

  • While complex integration requires a complex plan, the overall "program" (or sequence of projects) can't be cast in concrete too early.

A totally Agile methodology (i.e. scrum) may not make sense for an embedded system.

The Agile manifesto, however, provides ways to allow change to be possible without allowing simple chaos.

S.Lott
  • 45,522
  • 6
  • 93
  • 155
0

My issue with scrum in embedded systems is, there are many tasks to do, especially in the early stages, which are not demonstrable. We started with a dev board, no OS, no display, no serial comms, etc. We didn't have our display for 6 sprints.

The first 4 sprints were: Getting the RTOS up and running Creating tasks Writing network and serial drivers Writing interrupt routines for buttons, comms, etc Writing the primary database classes and methods Writing a serial debug menu

Most of these tasks are not well suited for user stories. In fact, the only interface into the whole system was the serial debug menu, built in sprint 3 so there was nothing to demonstrate at the end of the sprints. Even the serial menu was meant for internal use and not an end user.

Of course, each class we write has associated unit tests and we use a unit test framework to automate the execution of all tests.

We ended up writing "user stories" phrases like, "As a developer...", which I'm not happy with but in using Target Process (www.targetprocess.com), there is no concept of a backlog item which is a task or chore.

I'd love to hear how others have handled these situations.

Bruce
  • 441