我正在阅读 Marc 和 Laura Sewell （亚马逊链接）的《软件架构师的职业》一书，它让我想知道软件架构师是否是旧的非敏捷 BDUF 方法的一部分。
软件架构师在敏捷方法中是否有一席之地？我对 Scrum 特别感兴趣。
顺便说一句，我目前是一家大公司的 Unix 应用程序架构师。
干杯，
抢
Rob Wells
问问题
13133 次
15 回答
50
我在 Scrum 中作为架构师的角色包括以下内容。
技术尖峰——概念证明——我们将如何做到这一点。（“如果你直接使用 SMTP 库会更简单，它已经包装了现有的 SMTP 库；围绕我们的包装器编写你自己的包装器并没有多大帮助。我们可以添加你想要的方法。”）
开发人员之间的协调以适应预期的架构。（“嗯……你为什么要使用自己的属性文件？”
与用户合作以适当地确定积压工作的优先级。（“这三个是相关的，如果我们做一个，我们会以几乎零额外成本获得另外两个。”）
与管理人员合作以解决积压的问题。（不，项目经理不能这样做；他们没有技术深度。不，程序员不能这样做，他们没有概述。）
阐明为什么包名称是这样的，以及为什么数据模型具有这些功能。
找到我们遗漏的东西并根据技术理由重新确定积压工作的优先级（“我们将需要这个额外的冲刺来整合 [X]、升级 [Y] 并替换 [Z]，否则我们将永远无法完成这些冲刺。 ")
于 2008-10-07T10:02:41.400 回答
11
当然。
请记住 - 敏捷不是“给我带来摇滚乐”的方法。仍然有要求，仍然是设计，仍然需要可靠的架构。
当您正在构建产品或产品线并采用 Scrum 或其他敏捷方法来管理您的项目时，其中一个关键思想是开发一个较短的迭代周期，优先考虑要完成的任务，确定迭代中的内容A、B、C 等等。建筑师真正有价值的地方。让某人对 X、Y 和 Z 如何组合在一起有一个清晰的概念，可以使您的 Scrum 迭代更有效率。
于 2008-10-07T09:52:03.623 回答
7
敏捷开发并不意味着无政府主义开发，它仍然需要协调才能随着时间的推移保持可维护性。
但是......也许瀑布方法和敏捷方法之间的最大区别在于，您会在瀑布中找到软件架构师PERSON，您可能会在敏捷开发中找到软件架构师技能。我的意思是，随着人们一起工作的节奏越来越快，随着时间的推移，球洞团队的技能很有可能变得更加共享，这很好。
当然，软件架构师“领导者”将是保持全局并确保所有构建块一致的人，但随着时间的推移，他不会是唯一需要参考的人，因为他的知识将被传授给其他人。
于 2008-10-07T09:55:09.310 回答
6
绝对是的，尤其是在大中型项目上。架构师通过鸟瞰项目来提供技术指导，并负责评估和降低技术风险。开发人员的关注点往往较窄，较少受到高级别的关注。
于 2008-10-07T09:50:58.057 回答
4
绝对 - 在 Scrum 团队中需要并需要架构师。也许你不会从 scrum/agile 布道者、培训师等那里听到这一点，但任何有经验的产品负责人都会告诉你。架构师在 scrum 中的角色非常重要。
于 2012-02-01T18:41:37.700 回答
3
完全。
您提到的开发/项目过程是用于构建架构师所设计的东西。
所以经常使用的类比，建筑师设计和规划 - 城市，道路，建筑物。
开发商建造城市、道路和建筑物。
开发人员可以使用他们需要的任何项目管理系统来完成建筑、道路上的汽车和城市的运转。
正如建筑架构师随时与工程师一起监督建筑一样，软件架构师也应该随时监督开发过程。
建筑师和开发人员这两个角色是相关的 - 但可以遵循不同的流程来实现自己的工作计划。
于 2008-10-07T09:49:59.103 回答
2
我会说肯定有。尽管敏捷的重点是开发人员可以自由设计自己的代码，但仍然需要比单个开发人员工作的更高级别的整体程序设计。
于 2008-10-07T09:41:33.567 回答
2
然而......敏捷最适合小型项目，专业架构师通常在大型项目中更有用。
我认为可行的方式是架构师制定总体路线图并以 Scrum 方式与团队领导一起定义必要的模块。然而，随后团队领导和他们的 Scrum 团队进行实际开发。
一种两阶段的 Scrum。
于 2008-10-07T10:00:22.687 回答
1
我认为这更多的是技能问题而不是方法问题。所以是的，即使他有这个头衔，他也可能有一个角色。
于 2008-10-07T09:39:52.400 回答
1
即使在可能没有严格层次结构的敏捷方法中，程序员也不会是平等的。您将拥有经验丰富的活动家、初学者、了解代码库和问题域的人以及上述内容的组合。
我认为，虽然在真正的敏捷项目中可能没有“正式的”架构，但总是存在需要解决的架构问题，通常是更有经验的团队成员具备解决其中一些问题的知识。
还要记住，内部项目方法可能与薪酬等级是分开的——因此可以说“在职”在很大程度上可能会忽略头衔。
于 2008-10-07T10:04:01.087 回答
1
我们已经成功地实践了 1 年的 Scrum，我们的经验是有两件事必须平衡： - 系统架构是纯功能驱动开发环境中的重要“平衡点”。必须明确地进行技术层面的战略和中期规划，因为产品负责人专注于他们想要实现的下一个功能（这对他们来说当然可以）-另一方面，真正的敏捷意味着-系统架构师不应坐在象牙塔中（如前几篇文章所述）并设计仅在理论上可行的东西 - 应分发知识，以便每个团队都有足够的架构技能
我们的解决方案如下（我们在多团队环境中工作）：我们创建了一个由首席架构师（不属于 Scrum 团队的成员）的虚拟团队领导。每个团队就必须讨论的每个问题决定哪些成员希望参与讨论。团队做出共同决定。如果需要额外的工作，这可以通过一个新的用户故事来完成，或者如果它在 Scrum 之外很小。致力于决策的团队成员负责传达决策并控制其在团队内的执行。
于 2008-10-24T07:39:22.073 回答
0
绝对地。无论如何，没有理由必须预先完成架构。
于 2008-10-07T15:46:34.280 回答
0
是的，非常如此
“建筑师”是从建筑行业偷来的软件术语，旨在描述监督整个项目的人。建筑行业的建筑师是向结构工程师咨询项目外观和“人机界面”的人。可以在软件项目的构建“架构师”和“UX 设计师”之间建立更紧密的平行关系。我认为更贴切地描述软件架构师所做工作的术语是系统工程师。
那么软件架构在敏捷开发中的作用是什么？要理解这一点，了解敏捷软件开发的原则很重要。这些原则可以在此处的敏捷软件开发宣言中找到http://agilemanifesto.org
个人和交互超过流程和工具
工作软件优于综合文档
合同谈判中的客户协作
响应变化而不是遵循计划
更多信息在这里：http ://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/
于 2016-10-09T15:30:31.240 回答
0
首先：Scrum 团队是自组织的。这意味着技术管理角色没有得到太多表达。是的，团队可以选举/邀请成员担任角色。但在这个招聘角色中也应该委派给团队。是的..不是真的。除了团队的活动在会议和冲刺部分方面最强。技术架构提供史诗级别的解决方案，至少需要构建路线图、批准技术、反馈给利益相关者和其他特定的操作是我们的主题范围。此外，技术架构师的行为符合公司的企业发展利益，特别是为了保持 DRY 和其他解决方案重用、质量等原则。粗冲刺可以而且必须在多团队公司中相互关联，这也需要领导层的安排。在这些方面，架构师代表利益相关者，此外，作为实施主题的技术元素，约束，模式，技术是用户故事中的正确部分。基本上，在必要时，如果符合业务利益，架构师可以在 sprint 框架中编写代码（这在很大程度上取决于具体公司的领导代码，我认为这里没有什么超出范围的）。但是，架构师的定义角色是代表利益相关者进行业务到技术定义翻译和技术指南控制的技术解决方案 如果符合业务利益，架构师可以在 sprint 框架中编写代码（这在很大程度上取决于具体公司的领导代码，我认为这里没有什么超出范围的）。但是，架构师的定义角色是代表利益相关者进行业务到技术定义翻译和技术指南控制的技术解决方案 如果符合业务利益，架构师可以在 sprint 框架中编写代码（这在很大程度上取决于具体公司的领导代码，我认为这里没有什么超出范围的）。但是，架构师的定义角色是代表利益相关者进行业务到技术定义翻译和技术指南控制的技术解决方案
于 2017-02-21T11:46:39.810 回答
-3
我认为没有必要，因为由 SCRUM 的原始共振峰 Jeff Sutherland 博士和 Ken Schwaber 撰写的 SCRUM 指南没有提到需要。
于 2013-01-11T10:29:16.443 回答