我正在阅读Marc和Laura Sewell撰写的“The Software Architect's Profession”一书（Amazon link），这让我想知道软件架构师是否是旧的非敏捷BDUF方法的一部分。
软件架构师是否有敏捷方法的地方？我对Scrum特别感兴趣。
BTW我目前是一家大公司的Unix应用程序架构师。
欢呼声，
罗布
答案 0 :(得分：49)
我在Scrum担任架构师的角色包括以下内容。
技术峰值 - 概念证明 - 我们将如何做到这一点。 （“如果你只是直接使用SMTP库就会更简单，它已经包装了现有的SMTP库;在我们的包装器周围编写你自己的包装器并没有多大帮助。我们可以添加你想要的方法。”）
开发人员之间的协调以适应预期的架构。 （“嗯......你为什么要使用自己的属性文件？”
与用户合作，优先确定积压的优先顺序。 （“这三个是相关的，如果我们做一个，我们得到另外两个几乎零额外费用。”）
与经理合作以支付积压费用。 （不，项目经理不能这样做;他们没有技术深度。不，程序员不能这样做，他们没有概述。）
阐明包名称的原因，以及数据模型具有这些功能的原因。
找到我们所缺少的东西，并在技术方面重新确定积压的优先级（“我们将需要这个额外的冲刺来集成[X]，升级[Y]并替换[Z]或我们将从来没有完成那些冲刺。“）
答案 1 :(得分：11)
不确定
记住 - 敏捷不是一种“给我一块石头”的方法。仍有需求，仍然是设计，仍然需要坚实的架构。
当您构建产品或产品线并使用Scrum或其他敏捷方法来管理项目时，其中一个关键想法是开发一个简短的迭代周期，优先处理待完成的任务，确定要执行的操作在迭代A，B，C等中。建筑师可以真正有价值。让某人清楚地了解X，Y和Z如何组合在一起可以使您的Scrum迭代更加高效。
答案 2 :(得分：7)
敏捷开发并不意味着无政府主义者的发展，它仍然需要协调，以便随着时间的推移保持可维护性。
但是......也许瀑布方法论和敏捷方法论之间的最大区别在于，你会在瀑布中找到一个软件架构师PERSON，你可能会在敏捷开发中使用achitect SKILL软件。我的意思是，随着人们更加努力地工作，技能很有可能随着时间的推移而变得更加共享洞穴团队，这很好。
当然，软件架构师“领导者”将保持全局并确保所有构建块保持一致，但他不会是唯一一个随时间推荐的人，因为他的知识将教给其他人。
答案 3 :(得分：5)
绝对是的，特别是在中型到大型项目上。建筑师通过鸟瞰项目提供技术指导，并负责评估和降低技术风险。开发人员往往关注度较低，而且较少受到高层关注。
答案 4 :(得分：3)
共
您提到的开发/项目流程用于构建架构师所设计的内容。
经常使用的比喻，建筑师设计和规划 - 城市，道路，建筑物。
开发商建造城市，道路和建筑物。
开发商可以使用他们需要的项目管理系统来建设，道路上的汽车和城市运作。
正如建筑师可以随时与工程师一起监督建筑物，软件架构师也应该随时监督开发过程。
角色架构师和开发人员都是相关的 - 但可以按照不同的流程来实现他们自己的工作计划。
答案 5 :(得分：3)
绝对 - 在Scrum团队中需要和需要架构师。也许你不会从scrum /敏捷布道者，培训师等那里听到，但任何有经验的产品所有者都会告诉你。 architect's role in scrum非常重要。
答案 6 :(得分：2)
我会说肯定有。尽管敏捷的焦点在于开发人员可以自由设计他们自己的代码，但仍然需要一个比单个开发人员工作更高级别的整体程序设计。
答案 7 :(得分：1)
我认为这更像是技能问题，而不是方法问题。所以，即使他有这个头衔，他也可能有一个角色。
答案 8 :(得分：1)
然而......敏捷最适合小型项目，而专业建筑师通常在大型项目中更有用。
我认为的方式很有效，就是如果建筑师在所有路线图上做出规定，并以Scrum方式与团队领导者一起定义必要的模块。然而，团队领导和他们的Scrum团队进行实际开发。
有两个阶段的Scrum。
答案 9 :(得分：1)
即使在敏捷方法中，可能没有严格的层次结构，程序员也不会平等。你会有经验丰富的活动家，初学者，那些知道代码库和问题领域的人以及上述的组合。
我认为虽然在真正的敏捷项目中可能没有“正式”架构，但总是存在需要解决的架构问题，而且通常是更有经验的团队成员，他们将拥有解决其中一些问题的知识。的东西。
并且还要记住，内部项目方法可能与薪酬等级分开 - 因此可以说“在工作中”可能会忽略标题。
答案 10 :(得分：1)
+1 S. Lott的回答。建筑师的角色很重要，但是敏捷的方法要求建筑师从象牙塔下来并让他/她的手弄脏团队。这可能很难，因为象牙塔经常导致与创建软件的工艺脱节。
答案 11 :(得分：1)
我们已经成功地练习了Scrum 1年，而我们所经历的是有两件事需要平衡： - 系统架构是纯粹的功能驱动开发环境中的重要“平衡”。必须在技术层面进行战略和中期规划 由于产品所有者专注于他们想要实施的下一个功能（当然这对他们来说是好的），因此明确地完成了 - 另一方面，真正的敏捷意味着 - 系统建筑师不应该坐在象牙塔（如前几篇文章中所提到的）并设计仅在理论上有效的东西 - 应该分发知识，以便每个团队都有足够的建筑技能
我们的解决方案如下（我们在多团队环境中工作）： 我们由Lead Architect（不属于Scrum团队）创建了一个虚拟团队负责人。每个团队决定必须讨论的每个问题 哪些成员想参与讨论。团队做出了共同的决定。如果需要额外的工作，可以通过新的用户故事来完成 或者如果它在Scrum之外很小的话。为决策做出贡献的团队成员有责任传达决定 并控制其在团队中的执行。
答案 12 :(得分：0)
绝对。没有理由不必在前面完成架构。
答案 13 :(得分：0)
非常非常
'建筑师'是建筑行业的一个软件窃取期限，旨在描述一个监督整个项目的人。建筑行业的建筑师是指结构工程师就项目的外观和“人机界面”进行咨询的人。可以在软件项目的构造“架构师”和“UX设计者”之间绘制更接近的并行。我认为这个术语更贴切地描述了软件架构师的工作，是系统工程师。＆＃39;
那么软件架构在敏捷开发中的作用是什么？要理解这一点，了解敏捷软件开发的原理非常重要。这些原则可以在敏捷软件开发宣言http://agilemanifesto.org
中找到个人和流程与工具之间的互动
通过综合文档工作软件
合同谈判的客户合作
响应遵循计划的变更
此处提供更多信息：http://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/
答案 14 :(得分：0)
首先：Scrum团队是自我组织的。这意味着技术管理角色没有那么多表达。是的，团队可以选择/邀请成员担任角色。但在这个招聘角色中也应该委派给团队。是的..这不是真的。除此之外，团队的活动在会议和冲刺部分中最为强大。技术架构提供了史诗级别的解决方案，至少需要建立路线图，批准技术，反馈给利益相关者和其他具体操作是我们的主题范围。此外，技术架构师的行为符合公司的企业发展利益，特别是对于保持DRY和其他解决方案重用，质量等原则。粗多冲刺可以并且必须在多个团队公司中相互关联，这也需要在领导层面上进行安排。在这些方面，架构师代表利益相关者，而且，作为实现主题的技术元素，约束，模式，技术是用户故事中的正确部分。基本上，必要时，架构师可以在sprint框架中编写代码，如果它符合业务利益（这在很大程度上取决于具体公司的领导代码，我在这里看不到任何超出范围的东西）。但是，建筑师的定义角色是代表利益相关者进行技术定义翻译和技术指导控制的技术解决方案
答案 15 :(得分：-3)
我认为没有必要，因为SCRUM的原始共振者Jeff Sutherland博士和Ken Schwaber写的SCRUM指南没有提到需要。