Hi,
I also think, that after release we should run restrospective and actually
analyse how much reality differs from the spec. This will help us improve
planning in the future.
On 03 Feb 2015, at 22:15, Andrey Danin ada...@mirantis.com wrote:
I totally agree with Andrew.
On Tuesday,
The spec doesn't have to be perfect, but it needs to be merged prior to
code describing it.
Currently the spec has to be perfect and detailed enough, otherwise you
will have
to merge the spec with -1 from reviewers, also if you postpone the details,
you won't be able to track, if these details
Either we do specs, or we don't. Either every one has to land their specs
before code or no one does. Its that simple.
What should be sorted out? It is unavoidable that people will comment and
ask questions during development cycle.
I am not sure that merging spec as early as possible, and than
I totally agree with Andrew.
On Tuesday, February 3, 2015, Andrew Woodward xar...@gmail.com wrote:
Either we do specs, or we don't. Either every one has to land their specs
before code or no one does. Its that simple.
What should be sorted out? It is unavoidable that people will comment and
Hi,
+1 to Dmitriy's comment.
We can spend several month on polishing the spec, will it help
to release feature in time? I don't think so.
Also with your suggestion we'll get a lot of patches over 2 thousands
lines of code, after spec is merged. Huge patches reduce quality,
because it's too hard
Andrew,
What should be sorted out? It is unavoidable that people will comment and
ask questions during development cycle.
I am not sure that merging spec as early as possible, and than add comments
and different fixes is good strategy.
On the other hand we need to eliminate risks.. but how merging
