如何在scrum中记录和同行评审设计？

Question

我是一个相对较新的小企业开发人员(一个由3个开发人员组成的团队和一个同样小的QA分支)，在一个中等规模的系统上工作。当前的迭代仍然低于100 k行代码(服务器和客户端合并)，但我可以想象，从长远来看，总规模可能是200 kLOC或更多。我们正在尝试使用Scrum进行开发，我们正在努力实现CMMI级别2的评估。

我们正在采用同行评审的方法来验证我们的软件设计和源代码。我们在sprint计划会议期间引出软件需求，并将软件需求记录在主SRS中。这也让我们开始了软件设计，但是我们还没有一种正式的方法来回顾设计概念，比如OO设计、UI设计、可重用的设计模式等等。对于我们的源代码，我们正在尝试新的技术，例如使用电子表格来记录间接评审和电子邮件传递评论，但是对于审阅者来说，仅仅看源代码就很难理解设计概念。

(如果我曲解了概念，请原谅我，我们是在白手起家地尝试这么做。)

我们并不反对使用UML来表示类、对象、软件接口、事件模式或其他设计概念，但我们不确定何时或如何对我们的设计工作进行同行评审。通常，开发人员可以通过用户故事完成70+%，并意识到需要更改基本的设计元素(以及随后的同行评审)。

为了避免就这一主题进行公开讨论，并提出简明的答案，我将尝试提出两个具体问题：

1. 有没有人知道任何关于同行评审设计概念的最佳实践的好资源(如书籍、论文、文章)？
2. 我读过，代码本身就是(实现的)设计。对源代码的同行评审可以用作设计的同行评审吗？

谢谢。

Answer 1

我认为有三件事有助于良好的设计：

• 对编程。通过这种方式，您可以确保多个人知道设计是如何工作的，以及如何在不再适合当前需求的情况下更改设计。
• 单元测试。通过执行TDD，您可以确保设计足够简单，可以理解并随后进行更改。
• 时间到了。在迭代开发中，设计随着时间的推移而发展。没有人能告诉你，设计是好的还是坏的，目前它是创造的。只有在设计改变了几次之后，人们才能判断设计是否容易理解和改变。

问问自己，代码评审会给你带来什么。敏捷就是授权开发人员给他们自由来定义自己的过程。如果你不知道从某种过程中期望什么，那么很有可能你不需要这个过程。

Answer 2

如今，设计仅仅是在UX中完成的，他们在如何进行设计评审方面拥有大量的资源。

10分钟内会有很多人告诉你，你没有正确地做敏捷，忘了他们吧:你做软件是对的，软件不是一种宗教，敏捷就是。只要它能足够快地创建出好的软件，就可以了。

就我个人而言，我会做数据流图或任何东西，以确保在过程中的任何时刻都可以获得所有所需的信息。数据流及其好友(通过输入/输出处理等丰富的流程图)是捕获缺失元素的好方法。

UML的协同测试也很简单:你们中的一个人准备先把它写在纸上，然后收集团队，然后一步一步地在白板上画出来，问他的思路是否有问题。

在此过程中，请确保

• 首先，阐明给定设计的最终用户目标。
• 评估所有的需求，也许把它们写在白板上
• 画图
• 在绘图时表示有问题的地方，并强调它们。

我们几乎每天都有这样的设计会议，那时我在一家创业公司，与你现在的情况相当。

您也可以在源代码上这样做，但请永远记住:源代码是用来向计算机解释问题的。取决于所选择的语言和手头的问题，目前的语言在向人类解释它时可能是有效的，也可能不是。