软件开发的节奏

woza

传统软件开发模式的度量和管理难题之一是整个过程中，由于阶段的划分，造成开发团队无法控制节奏。没有节奏就意味着不稳定，难度量，难管理。
敏捷以及精益开发模式中，比较容易做的有节奏的开发。由于取消了分阶段的开发方式，跨功能的团队中所有人的Workload在整个开发过程中都比较平均。一般也不会发生由于某个瓶颈而造成整个团队等待之类的问题。团队中合作伙伴是固定的，因此默契可以随着时间的推移而逐步形成。此时，整个开发团队就可以形成稳定的节奏。有了稳定的节奏，整个开发过程的可控性和可估计性将大大加强。而且团队的节奏一旦产生，不会轻易的被人员变动所打破。这样一来，风险就降低了。类似于加班，deadline之前的疯狂之类的现象都将消失。

[ 本帖最后由 woza 于 2009-8-10 09:35 编辑 ]

woza

传统模式下，开发，测试，需求分离。无法一起工作，当然很难有默契。没有默契何谈节奏。另外每个角色忙时很忙，空时很空，deadline冲刺更是常见。这个难道不是模式问题？

欢迎拍砖。

shanglikathe

关于开发和测试的节奏是一个常见问题，一方面开发要赶进度；另一方面测试又希望吧所有的缺陷都修复完成。

但是彼此在工作过程中总有这样那样的不匹配。我们是不是可以转换一下思路，看能否找到一个双赢的策略。一方面既可以保证开发的进度，另一方面又可以保证测试的充分性。

对于开发而言，他们关注的是赶快把代码提交，希望测试人员能够尽快的发现较严重的缺陷，因为开发人员倒不担心有缺陷，他们最怕的是有严重程度而且很难改的缺陷发现太晚。

对于测试而言，最关注的是不要有漏测的问题，尤其是一些严重性缺陷，千万不要等到软件到用户手上，让用户发现了这一类问题，这就是万劫不复了！

针对我们双方的终极目标，其实可以定义明确的版本目标。测试可以不用每一个版本都是完全测试，开发也不需要将每个版本的bug一并全部进行修改，可以分阶段修复。这样我们可以共同攻下一个稳定版本之后，再继续攻下一个版本！