并发编程网 - ifeve.com

作者：方腾飞

最近在参与一个比较大的项目，需要耗费上千人日，而细分设计和设计评审就花掉了几百人日，基本上10几个人写了几周的设计文档，并开了几周的设计评审会。整个过程模式比较重，所以耗费的人力比较大。

为什么模式比较重？

• 参与者众多。设计评审会时，要求与本会相关的人都参与设计评审，一个屋子里可能坐着几十人，哪怕一个小时的会议和你相关的就5分钟，你也要参加。而且这样的公司会议太多，如果每个相关的会议都去参加，那就基本上是白天开会，晚上写代码的节奏，所以现在当有人找我开会时，我会问是否必须要我参加，能否会前或会后找我沟通确认，可能10分钟就能解决的问题。
• 设计文档内容多。系分设计非常全，需要把所有设计场景都写上去，首先需要花大量时间写系分设计文档，其次需要几个小时的会才能评审完。而这样全面的设计文档，可能需要三个月到半年才能开发完成。
• 有的设计评审没有经过小范围初审，有些设计遗漏了，导致要反复评审。

​这样的详细设计和设计评审虽然模式比较重，但是优点是考虑的很全面，风险在一开始都能大部分暴露出来，缺点就是耗费的人力太多，不够敏捷。所以本文想和大家一起探讨下敏捷设计，希望能抛砖引玉！

在谈敏捷设计前，首先需要思考下到底什么是软件设计？在精益思想中对于浪费有这样的定义，任何不对最终客户产生价值的行为都是浪费，而设计本身是不对客户产生任何价值的，那么为什么需要进行软件设计？

什么是软件设计？

大学应用基础是这么定义的，软件设计是从软件需求规格说明书出发，根据需求分析阶段确定的功能，设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。我总结下，软件设计是将需求抽象成软件系统的过程。

为什么需要软件设计？

因为好的设计可以降低成本，如减少返工，当需求变更时，能快速响应需求，并且开发成本最低。

什么是敏捷设计？

在网上找了下定义，致力于保持系统设计在任何时间都尽可能的简单、干净、以及富有表现力！其实就是减轻设计阶段的压力，最大程度上减少浪费，多余的设计和考虑不周全的设计都会造成浪费。有些文章谈到代码就是设计，这个有点理想化不好落地，简单的项目可以这么做，但是像我们做的互联网金融产品，业务都极其复杂，光看代码是很难看懂的。

如何进行敏捷设计？

我总结出的几个思路，可能比较概念化：

• 分阶段设计。先设计必须要的东西，快速拿到产出，暂时不用的先不要设计，想不清楚的也暂时不要设计。没事的时候就多想想系统的设计有没有问题，有问题即时提出来，然后修改掉。
• 快速讨论设计方案。自己设计出来的东西先找某个同事简单过下，如果在设计评审中还有很多问题，那浪费的人日会更多，因为参与设计评审的人很多，不通过还要开复审。一只笔，一个黑板擦，一面玻璃板足以完成一次设计，用笔直接在板上画一下自己的设计思路，并和同事进行讨论，确认之后把设计图拍照提交到文档库，或者用工具Visual Paradigm画出来。
• 不需要的不设计。优先以最小人力解决问题，能用简单的方法解决问题，就不要用复杂的办法。比如，能通过打通网络解决系统间访问问题，就不要走代理，这样可以节约很大的设计和开发成本。能通过业务解决的问题，就不要想用系统解决，比如人工操作修改数据，和系统启定时任务批量修改数据。

敏捷设计的优缺点

优点：互联网开发业务变化得非常快，如今天产品经理觉得应该上旗舰版来提高产品的销售额，但是几个月后发现由于价格比较贵，购买的人比较少，于是旗舰版就分拆成不同的模块进行售卖。从我们的经验来看，一个扩展性非常好的业务设计可会带来三个问题，第一设计和开发时间比较长，第二代码不易读，第三大部分扩展以后都不会用到。 所以敏捷设计的思路是只做必要的设计，需要的时候再重构。

缺点：可能的确是有些场景在设计的时候没有考虑到，导致系统在未来很特殊的场景下不能支持业务需求。到时候可能就需要打补丁或者用很奇怪的方式实现。

敏捷设计评审会议

• 减少会议。为了会议的高效，我们之前的做法是会合并几个会议，在Kick Off会议之后直接进入设计评审会议，因为定会议室，投影仪，让参会人员准时参加都需要一定的成本。设计评审会议一般是半个小时到1个小时。设计者讲下自己的设计，可以使用PPT或直接在黑板上画一下自己的想法。如果是对已有功能的修改，需要先讲这块功能原来是什么样，现在需要修改成什么样，涉及到哪些修改点，自己是如何设计的。如果设计方案审批不通过，则设计者需返工，因为我们强调简单设计，所以即使返工，成本也不会很高。同样为了高效，设计者重新设计的方案不需要再开一次设计评审会议，只需要把相关人叫到座位旁边确认下就可以。
• 减少参与者。只邀请必须参加的人，非必须单相关的单独沟通。
• 高效评审。设计评审中很重要的一点是参加评审的人必须有足够的耐心和胸怀听明白别人的设计，设计评审是为了优化设计者的设计方案，而不是为了挑战设计者，或给设计者挑刺。任何设计方案都有它的优缺点，所以评审人在听完设计之后，需要先思考下这个设计方案的优缺点是什么，再想想自己的设计方案是什么？对于设计者没有考虑或讲到的点，可以通过反问的方式让对方补充。