软件设计会议程序

Question

我和我的团队成员在执行设计会议时遇到了一些困难。症状如下：

1. 我们很容易偏离轨道，对系统内容的低理解和希望解决方案成为您的解决方案的组合经常会驱动对话。
2. 我们无法得出一个可以接受的结论。通常，开发人员和系统架构师由于架构师参与低级别设计而存在问题。
3. 坚持自上而下的方法的能力，通常在高层次设计完成之前深入到组件中。我相信这是因为会议成员的设计思想有很大的不同。

我认为解决这些问题的办法是更好地理解设计方法。我感兴趣的是：

1. 关于改进的建议，但更重要的是
2. 一个很好的方式来进行软件设计会议的实施者和软件架构师，从文献，可以阅读。
3. 一种技术或指导如何优化方法设计(不是体系结构，而是高级设计和类图之间的步骤)，以便开发人员和架构师能够采用通用的设计方法。理想情况下，引用可读的、可发行的、有信誉的文献是理想的，因此它可以被所有人阅读和同意。

Answer 1

有些事情你可能希望改善一下

Agenda

列出一组需要讨论的主题，并将自己限制在这些主题上(至少在一开始是这样)。

时间盒讨论

每一议程项目的时间表。如果它看起来像是要掉下来的，那就离线，或者把它撞到另一个会议上。

限制与会者

您可以停止讨论失控，我限制出席人数，或将设计会议分成多个会议。如果你能让与会者事先考虑一下议程项目，那就会有麻烦了。

调度

承认设计会议可以涵盖多个会话。考虑一下什么时候最适合安排会议，以使与会者得到最好的结果。

在可能的情况下取得进展

如果某一议程项目被否决，请随意停放，然后转到一个可能达成共识的项目上。如果取得了一些进展，就可能对所有缔约方更积极地看待这次会议。

限制可用选项

如果设计功能没有意义，请限制可用的选项。即使你不能做到这一点，你至少可以排除一些选择(从以前的项目经验)。

Answer 2

你正在经历的问题主要是工作场所的问题，但是我相信这些问题的根源在于人们在软件工程过程中所扮演的角色。可能缺少一个角色(业务分析)也可能有帮助。

我们很容易脱轨，结合了对系统内容的低理解。

这可能表示您需要进行业务分析，或者需要有人收集需求，了解客户端存在的问题，以及软件如何解决这些问题。

..。并希望解决方案成为你的解决方案，经常推动对话。

这是一个人的问题，这是这个网站的主题。

我们无法得出一个可以接受的结论。通常，开发人员和系统架构师由于架构师参与低级别设计而存在问题。

虽然这可能是一个“人的问题”，但它确实与软件工程特别相关。架构师应该做出诸如“这将是一个web应用程序”和“我们将使用一个关系数据库”和“它将使用微服务”这样的决策。

有关低级别组件的决策应该委托给工程团队中的首席开发人员。职责分离，将适用于这里。

坚持自上而下的方法的能力，通常在高层次设计完成之前深入到组件中。我相信这是因为会议成员的设计思想有很大的不同。

这很可能是因为人们“在高级设计完成之前就深入到组件中去了。”在考虑较低层次之前，需要完成高层次的设计。

Answer 3

不要邀请不该参加会议的人。

例如，在讨论低层次设计时，架构师甚至不应该在场。只邀请了解系统的人，在那次会议上讨论的层次。

不尝试在一次大型会议中进行架构、高层设计和低级设计。

自上而下地设计。单独开会。在你决定了这件事的意义之前，不要去想低层次的设计。