Olin Lathrop wrote in [TECH] Agile programming:
> The obvious approach to me is to gather the requirements you can up front,
> take a stab at a reasonable architecture based on what you know, then 
> start
> implementing.  The requirements will always change at least a little. 
> With
> good architecture and with some experience with what is likely to change,
> the little changes don't usually require large structural changes.  If
> something does require large structural changes you're no worse off than 
> in
> your system.  Often enough though you do get enough right up front for 
> that
> to be useful and therefore save effort in the long run.

I have absolutely no problem with what you've said above, as long as the 
scope of "gather the requirements up front" is limited to what you need for 
the first iteration (I know I've said it before, I'll address it in more 
detail below).


>> First, I would create a quick sketch on a napkin or better yet, a
>> whiteboard. I would draw a quick block diagram, and a simple drawing of
>> the
>> product's appearance. "Is this what you want? Do you want 12 hr or 24 hr?
>> How many users would this NTP server serve? Etc."
>
> But you're not allowed to do that as it's not required for the first
> iteration.  You seem to understand intuitively that this up front planning
> is required, but note how this is a lot more than planning for just the 
> next
> iteration.  You have to have some idea where you're ultimately going 
> before
> you put your head down and dig in to get that first chunk done.

Aha! So this is what's creating the confusion. :)

The difference between planning for the first iteration and for the entire 
project is subtle, but very profound.

When you're planning for the first iteration, you look at the big picture 
first. What are the high-level requirements? Ok, so this gadget must have an 
LCD, four buttons, a USB port, five A/D channels, and the firmware must be 
upgradeable.

Now let's decide which features will be implemented in the first 
iteration -- let's say, reading the A/D channels and displaying the output 
on the LCD. These are the only things that need to be spec'd out in detail. 
On a medium-sized project (say, three months) this means that only..

    (2 weeks/iteration)/12 weeks * 100% = 17%

... of the functionality must be hashed out in detail. It doesn't make sense 
to be hashing out the details of the secure bootloader and the kind of 
encryption scheme it will be using, until we get to it. High-level 
requirements are good enough for the first iteration. The bootloader may not 
be implemented at all, so creating the specs for it could end up being a 
complete waste of time.

I am contrasting this with doing 100% (or close to it) of the planning and 
design work upfront.


>> Once I think I understand what you need (after 30 minutes of sketching 
>> and
>> asking questions), maybe I could even construct a simple cardboard model.
>> Does it look like you imagined it?
>>
>> We could breadboard a part of the circuit, let's see if the 7-segment LED
>> is
>> big enough/bright enough. "You want a different color? No problem, let's
>> try
>> this one. Looks OK? Great!"
>>
>> I would get your feedback as I sit down to do the schematic, and later 
>> the
>> layout. In parallel, I could put together bits of working code, and
>> demonstrate them to you (sync code, UI, NTP server).
>
> I mostly agree with this, but this is not the process as you have 
> previously
> described it.  This is looking ahead a lot more than a single iteration.

No, not really. All of what I described would be done over several 
iterations. But I would say that most could be done during the initial 
meeting.


>> What I would *not* do, is try to commit every single detail down to 
>> paper,
>> before doing any actual work.
>
> If this were a fixed price project, then lots of details had better be
> written down, both for your protection and mine.  These details are the
> what, not the how.

I don't do consulting, but I believe you that this is probably how it is 
done in the majority of the cases. The problem is that initially, the 
customer does not know exactly what he wants. You can try to get him to 
think of everything, and commit it to paper. Or you can build a series of 
prototypes that gradually approach the final product.

In fact, that is the whole point of agile contracts: they mostly describe 
the approach and the expectations, not the end result.


>>> Code yes, but you do have to architect the system for the full feature
>>> set.
>>
>> Not in my experience. It is possible to start with a simple system with
>> only
>> a subset of the final feature set, and build/refactor it into the final
>> system.
>
> I guess this is the fundamental disagreement that will remain a
> disagreement.

Olin, well don't you ever start with a set of requirements for a product, 
and then add more features to this product? Couldn't you then say that the 
initial design had only a subset of the functionality? It is done all the 
time, you start with a simple design and eventually add more bells and 
whistles.


Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist