Hi Nikolai,
On 10/30/06, Nikolai Pretzell <[EMAIL PROTECTED]> wrote:
Hi Kohei,
Kohei Yoshida schrieb:
> On 10/27/06, Nikolai Pretzell <[EMAIL PROTECTED]> wrote:
>> Kohei Yoshida schrieb:
>
>> > In a not-so-ideal world, things don't always go as planned.
>> > Requirements grow organically over the development life cycle of that
>> > feature, but the spec document may not always get updated.
>>
>> There is a clear rule in the current spec process: Spec and code have to
>> be in sync exactly when the CWS is set to the state "ready for QA". It
>> may be earlier but that is not required. It must not be later.
>
> Again, you just stated the current rule, but is it actually working as
> expected? ;-)
Not always. But is that a reason not to try?
If there is a clear benefit of doing this, then yes. Otherwise, no.
But I wouldn't want to try spec'ing every minute detail of a feature,
and keep it in sync with the code all the time. And that, to me, is
what the specification project is requiring us to do (well, probably
not "all the time", but close).
There are mainly two complaints I have with the current specification project:
1) It asks for way too many details, especially in the UI design
section. It's not too bad if the feature involves only one
control/widget change. But once the change involves three or more
dialogs, with each dialog having an average of 7 to 8 controls, it
starts to become a real pain in the rear, aside from the fact that the
Basic runs and errors everytime I change the value of that combo box
(ok, I'll stop complaining about this because I think I've already got
my point across to the right person :-).
2) The target audience is not very clear. Thanks to this thread,
though, now I'm beginning to see who the specification documents are
intended for (mostly for QA, right?). But without knowing who will
actually read my specification and how my spec will get used, I'd have
hard time setting the right level of granularity so that I can do
absolutely minimal but still make my spec document useful for someone.
Call me lazy, but when I'm writing a spec, I don't feel productive, so
I just want to get it over with as quickly as possible. Aside from
the fact that, when I'm trying to write a spec late at night after my
kids are asleep, my motivation meter begins to fall rapidly, and my
typing speed begins to crawl. ;-)
"Responsible" does not mean he has to do the actual work. But the
developer is the one who after all sets a task to fixed. He cannot do
this, if the spec is not in sync, because either the implementation is
buggy or the spec. In the latter case the QA cannot test (it verifies
against the spec, what else?). And a feature that cannot be verified is
not yet done.
I don't doubt that this is how you guys do your work, and I have
nothing against it.
But doesn't an externally contributed feature come pretty much when
it's complete (or nearly so)? If so, then a spec is written after the
fact, which means the spec can be easily retrofitted to be "in sync
with the code". In this scenario, a spec cannot be used to verify the
implementation, because the implementation is done first. You can do
the opposite, perhaps, to verify the spec against the implementation.
I did that for my first specification (natural sort), and I'll
probably do it for my second spec (solver), too.
So, my workflow seems different from yours, which itself may be a
problem when being involved in this project. But that's how I write
my code in my free time.
Who actually does the change (in spec or code) is an internal problem of
the I-team and they should come to a consensus within that team, IMO.
Ah, I-Team. By the way, I usually work on my feature alone, with
occasional patches received from the ooo-build team for build fixes
etc and with occasional consultation from the Calc team and the
ooo-build team. But, for the most part, I'm usually the only guy for
my feature. :-) And I imagine this setting is not uncommon among
community hackers who contribute codes (I may be wrong though).
>> Actually, every feature that changes behaviour needs a spec.
Or, as Thorsten wrote, the already existing spec may need to be updated.
That's easier. Thanks. :-)
>> How else
>> should the QA be able to test the new feature? Against what should it do
>> that testing?
>
> IMHO a feature description, and in case of ambiguities, an email or
> two to the developers asking for clarification should suffice for most
> cases (e.g. feature A introduce a new check box. When it's checked,
> it does X, when it's not checked, it does Y The check box should have
> the label that reads "Enable XYZ").
A feature description is a spec, isn't it?
Not to my mind. I think of a feature description as an overview of
the feature, something you'd use for documentation purposes. It is
more paragraph-oriented than table-oriented, i.e. the details are not
usually quantified.
I think of a specification much more rigorous, outlining (nearly)
every corner of it with little ambiguity.
Except of that the contents
of the clarifying emails need to be transfered into it, too, because
else that information is lost (for the QA for example).
Sure. I don't dispute that.
Why we use a template is only, because it is easy to forget things, for
example: Did I think about all error conditions? The template tries to
reduce the chance of forgetting.
Sure. A template is useful for this purpose, yes.
Kohei
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
