Let’s say you were an embedded systems developer, and you were planning on attending a conference like the Deep Agile Embedded.
What questions would you hope you could get answers for at the conference?
What if you already knew it all but were sending your boss, co-worker, or CEO who needed to learn more, what would you want them to hear about?
Would you want to do some hands on Test Driven Development?
Here are some of the questions we have so far:
- In practice, how can a hardware-based system be delivered incrementally? Isn’t it more work – and more expense – to do it that way?
- With agile iterations only a few weeks long, do agile teams really expect to modify hardware that frequently?
- Extreme Programming says that you need to have an onsite customer. But so many embedded systems have thousands of customers who are not even aware of the system – e.g. if your software controls anti-lock brakes in a car, how can a car buyer be expected to interact with the team to help them design that software?
- Because hardware lead-times are long, don’t you have to design most of the system up-front? Isn’t this against what agile calls for?
- If you’re planning an iteration at a time, how can you possibly be sure of hitting a hard deadline?
- How can you do automated test on software that is driving device hardware – like motors, or sensors?
- Embedded systems and software are not delivered incrementally, doesn’t that make Agile inappropriate for most embedded development?
- In embedded systems development hardware, software and mechanics are built concurrently. That means a BDUF is needed. Comments?
- Some embedded software deliverables, take more than 2 weeks to deliver, a device driver for example, also it is not visible to the “customer”, how does agile handle that?
- Hardware is often not ready until late in the product cycle, how can testing be continuous from the beginning without hardware.
- We only get one chance to deliver, how can you say that some features will be cut.
- We had a team doing agile. To them that included not doing any documentation. We need documentation once we go into maintenance. Is doing documentation allowed in Agile?
- When the features are broken into little pieces and ordered by the customer, what if something near the end of the release causes major rework?
- I’m concerned about the lack of up-front design. What if some story causes a lot of rework to the current design?