Hi,
Kohei Yoshida schrieb:
The problem with the current specification process from my own
experience and observation is that, it puts the wrong focus on the
purpose that the project is intended to serve.
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.
Ideally, the developer should also be responsible for updating the
spec document to ensure that it keeps up with the requirement change
over the development cycle.
The developer not only should be, but is responsible for this.
Unfortunately, writing a spec is a requirement for a feature that
requires a UI change, such as the feature I'm trying to get
integrated[3]. So, getting no response whatsoever means that, this
feature has to wait until either 1) someone be kind enough to give me
help figuring out what the problem is, 2) I have to go through all the
Basic code myself and figure out how to fix it (there is quite a bit
of code to go through), or 3) integrate it but disable it in the
default build, to avoid UI change (no UI, no spec).
Actually, every feature that changes behaviour needs a spec. How else
should the QA be able to test the new feature? Against what should it do
that testing?
Nikolai
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
