软件设计期......其他开发人员做了什么？

Question

我是一名新的软件架构师/负责人，为软件开发人员团队提供软件设计。我想出了需求规范，接口头文件和visio软件设计文档，以及构建计划等。

我的问题是：在此期间，团队的其他成员会做些什么？我当然让他们参与设计，但我们并不需要整个团队积极致力于我一直在做的事情。

新软件架构师有没有好书？

Answer 1

通常各个阶段重叠，因此在设计过程中会有一些编码等。除此之外还有很多事情要做。他们可以审查将要使用的不熟悉的技术，设置源控制系统，审查业务要求，审查您的文档以确保它们有意义且清晰。除了编程之外还有很多其他的工作要做。

Answer 2

停止做你做的无用的事情，然后开始用它们编码！ ;）

Answer 3

软件团队的工作方式虽然领先，但公司之间的设计却截然不同。在我的公司，我们尝试着手设计，而开发人员正在最终确定其他项目或解决错误。

我在开始一个全新项目时采用的另一种方法是让开发人员也参与设计工作 - 对需求有深入了解的人可以帮助您设计系统的较小部分并编写规范对他们来说其他可以在模型和框架上工作。这对于我在之前的工作中领导的小型软件团队（总共4个开发人员）非常有效。

Answer 4

如果没有与另一个正在进行的项目重叠，那么让他们参与进来是非常好的，也许可以通过让他们进行原型设计并提供替代技术的优缺点（API，框架，库，等......）你的项目可以使用。

Answer 5

正如其他人所说，您通常需要在项目的第一部分和第一次迭代期间加速。 你计划迭代地构建这个，不是吗？从核心团队开始（不超过3-4人，因为你需要彼此进行大量沟通）帮助您探索需求，获得基本数据模型，识别和设置任何框架，识别和设置构建和测试工具。一些编码活动通常发生在设计阶段：对于技术敏感区域的 UI模型，预先运行原型（无论您有什么风险，都应该通过解释性编码来缓解：be他们新技术，集成系统的未记录接口，或不稳定需求）。

但是设计阶段的编码员应该帮助设计，以获得他们的支持，并在第一次迭代期间帮助培训团队的其他成员。您在此期间的角色是确保主要nonfunctional requirements（例如，已知，优先，设计满足，并且可以进行测试）。您还应该与项目负责人或其他负责人员配备和融资的人员合作，以便勾勒出所需的迭代次数和人员配备水平。确保解决方案可以迭代构建，并且旨在实现第一次迭代期间的基本结构，既可以建立信心，又可以消除风险。 （有时，您可以将主要风险推向第二次迭代，并首先关注信心和团队建设。）

当然，请确保您没有设计每个细节。您应该能够在下一次迭代中使用每个设计工件（并在以后根据需要详细说明）。由于设计决策变得昂贵，因此请尝试推迟。但是，有些会影响整个解决方案（例如，数据模型或您的安全方法），绝对必须至少预先列出。这不是瀑布。这只是没有闭上眼睛，希望通过魔法出现一个可行的架构。

但设计在整个迭代过程中进行。只是你随着时间的推移做的更少，对解决方案的影响较小（除非你运气不好......然后事情变得昂贵）。

Answer 6

通常他们可以处理另一个项目，但是......

我让我的团队审查项目规范/要求，并整理一个基本/初步结构，让他们已经考虑整个应用程序并制定具体问题。

当我们在桌旁召开会议讨论计划时，他们已经知道项目的内容和要求，在某些情况下，他们会提出我可能错过或忽略的问题。

Answer 7

如果您的团队没有任何其他项目可以处理，请让您团队中有经验的程序员提出原型，以便您可以根据客户的需求创建需求文档。

对于团队中使用的技术的新手程序员也可以利用这段时间熟悉团队开发项目的技术。

Answer 8

虽然现在已经太晚了，但接近它的一个好方法是在当前项目结束之前将架构师移开。开始以25％的速度释放他，然后在新项目启动之前的一两个月内以高达75-100％的速度工作（可能更多取决于分析和客户互动的程度）。

在一个微不足道的项目上（假设2个人年），它可能没有必要，但是如果有人在每个人都跳上之前没有得到正确的分析，那么任何大于此的东西都会陷入混乱。

Answer 9

architect！= designer

有可能所有开发人员都可以帮助设计;让他们。建筑师不必是“孤狼”，而是自己做所有事情。您可以在布线中列出准则，原则和脚手架，并让您的开发人员充实细节 - 无论是绘制Visio图表还是构建原型以减轻未知/风险。

迁移到敏捷/ XP并远离瀑布式方法，你会发现团队更多的帮助。

Answer 10

在进行一般设计时，让程序员创建概念验证非常方便。尤其是系统的某些部分，如果它们不按照您计划的方式工作，最终可能会显示停止者，这样您就可以考虑替代方案，并调整设计。

这将帮助您在完全进入某个方向之前做出正确的设计决策。

只是进行设计，然后继续并开始编码是弄乱项目的可靠方法。在你进行中途编码之前，你不会意识到你的设计是不可行的（或者只是简单的糟糕），到那时为时已经太彻底了，无法进行彻底的修改。

您将浪费时间在设计过程中缓解不存在的问题，并且在实施过程中会遇到无法预料的问题。