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? ;-) Is the spec always successfully kept in sync with the code? Even if an effort is made to update the spec to match the code, does the spec always accurately and clearly describe what the code does? If there is any discrepancy between what the spec says the feature should do and how the code implements the feature, is that a bug in the implementation, or a bug in the spec? (you may say the spec should be always accurate, but there are cases where such assumption does not hold).
> 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.
Again, that's the current rule, and the point of this thread, as far as I understand, is to question such rule. Of course, IMO it's reasonable to have the developer provide a feature description, provided that the feature was originally his/her idea. But occasionally someone who requests a feature writes a detailed, 20-page spec for a feature of mild complexity, and that individual is not a developer hence cannot work on the implementation. And, say, one developer with good will volunteers to implement that feature, and is told that it is the developer's responsibility to make sure that the spec is kept in sync with the implementation. A month later, there is a meeting (or discussion) between developers and non-developers and a conclusion is reached to change one or two aspects of that feature. In this particular scenario, I don't think it's reasonable to assign the task of updating the spec to the implementor alone. I also have this question: does every developer at Sun/StarDivision successfully maintain the specs he/she wrote, and all specs posted on the specs website currently reflect the current state of their respective feature they describe with clear descriptions and no ambiguities or errors?
> 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?
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"). If a feature has some complex element, then the developer may need to be involved to provide more assistance, but the developer's involvement, or a spec, should not be a mandatory policy for all cases. Just my opinion. Agree or disagree? Up to you. :-) Kohei --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
