我是一个新的软件架构师/领导,为一个软件开发团队提供软件设计。我正在准备需求说明书、接口头文件、visio软件设计文档和构建计划等。
我的问题是:团队的其他成员在这段时间里做了什么?我当然会让他们参与设计,但我们不需要整个团队都在积极地做我一直在做的事情。
有没有适合新软件架构师的好书?
发布于 2009-04-03 20:29:18
正如其他人所说的那样,您通常希望在项目的第一部分和第一次迭代期间有一个加速阶段。你正计划迭代地构建它,不是吗?从一个核心团队开始(不超过3-4个人,因为你们将需要彼此进行大量的沟通)来帮助你探索需求,获得basic数据模型,识别和设置任何框架,识别和设置build和测试<代码>E29>工具。一些编码活动通常发生在设计阶段:对于技术敏感区域的UI模型、run-ahead prototypes (任何风险都应该通过显式编码来减轻:无论是新技术代码、到集成系统的未记录接口,还是不稳定需求<代码>E219>)。
但设计阶段的程序员应该帮助设计,以便获得他们的认可,并在第一次迭代期间帮助培训团队的其余成员。在此过程中,您的角色是确保主要的nonfunctional requirements (例如,已知的、确定优先级的、设计满足的、可测试的)。您还应该与项目负责人或任何其他负责人员配备和融资的人合作,以便勾勒出所需的迭代和人员配备级别。确保可以迭代地构建解决方案,并在第一次迭代期间仅实现基本结构,以建立信心和消除风险。(有时,您可以将主要风险推到第二次迭代中,并将第一次迭代的重点放在信心和团队建设上。)
当然,要确保你没有设计好每一个细节。您应该能够在下一次迭代中使用每个设计工件(并在以后根据需要详细说明它们)。因为改变设计决策的代价很高,所以尽量推迟它们。但是,有些问题会影响整个解决方案(例如,数据模型或您的安全性方法),并且必须至少在前面列出。这不是瀑布。这并不是闭上你的眼睛,希望一个可行的架构会神奇地出现。
但是设计在整个迭代过程中都在进行。这只是你在进行的过程中做的更少,对解决方案的影响也更小(除非你不走运……然后事情变得昂贵)。
发布于 2009-04-03 19:10:41
通常不同的阶段是重叠的,所以在设计过程中会有一些编码等,除此之外还有很多事情要做。他们可以审查即将使用的不熟悉的技术,设置源代码控制系统,审查业务需求,审查您的文档以确保它们有意义和清晰。除了编程之外,还有很多其他的工作要做。
发布于 2009-04-03 19:13:50
停止做你做的无用的事情,开始用它们编码吧!;)
https://stackoverflow.com/questions/715225
复制相似问题