需要大量设计的软件如何进行敏捷开发

最近被两次问到同一个问题：如果一个软件需要大量密集的设计工作，导致存在独立的设计和开发团队，应如何实施敏捷开发？

整体上讲，敏捷开发不希望存在设计和开发的分离，因为这样就会产生“设计文档”这种东西，而且因为两个团队分离，设计文档一定相当详尽，而且在交接的时候多半要进行评审，否则很难保证开发团队能理解并按其编写代码，最终还可能会导致两个团队的矛盾。

在敏捷开发中一般这样处理这种情况：将设计人员下放到开发团队中，由于他们一般技术水平高于开发人员，所以可以作为139团队的骨干（请参考“139团队”相关的博文），一方面继续自己的设计工作，另一方面带领自己的小组进行开发。由于两者关系拉近，设计文档即使不能被取消，也不会需要编写得过于详尽，尤其可以忽略那些“没有就开发不出来产品，而产品开发出来后就没用了”的内容。此外设计人员的高水平也会在日常工作中带动开发人员的设计意识，达到“设计人员在设计的同时考虑到如何开发，开发人员在开发的同时理解为何如此设计”的水乳交融的状态。

对于真的需要多个人碰头才能完成的架构设计工作，则需要这几个负责设计的人员共同完成（就是139中的13人员）。这里顺便说另外一个刚刚被问到的问题：倘若敏捷团队是一个新建的项目人员还在扩张，应如何计划人力资源？答案是应该优先选择和招募骨干人员，让他们先把需求分析/架构设计这些困难的工作做起来（在Sprint0里边打基础，之后每个Sprint完善），之后在迭代中逐步吸纳初级人员，做过游戏开发的一定对这个过程不陌生。

另一个相关的问题是：不要把一堆新手凑一个开发团队来独自做低级编码工作。这个喜欢玩球类运动的人一定知道：如果团队中没有高手带着，大家的水平并不会因为工作经验积累而有实质性的提升，相反引入若干高手指导其工作，才是让团队尽快成长的良策。这一点也支持将设计与编码团队合并的方案。