软件架构师是否在敏捷方面发挥作用,尤其是.争球？

我在读这本书"软件架构师的职业",由马克和劳拉·休厄尔(亚马逊链接),它让我想一个软件架构师是否是旧的非敏捷BDUF方法的一部分.

软件架构师是否有灵活处理的地方？我对Scrum特别感兴趣.

BTW我目前是一家大公司的Unix应用程序架构师.

干杯,

抢

我在Scrum担任架构师的角色包括以下内容.

技术峰值 - 概念证明 - 我们将如何做到这一点.("如果你只是直接使用SMTP库会更简单,它已经包装了现有的SMTP库;在我们的包装器周围编写你自己的包装器并没有多大帮助.我们可以添加你想要的方法.")

开发人员之间的协调以适应预期的架构.("嗯......你为什么要使用自己的属性文件？"

与用户合作以适当地确定积压的优先顺序.("这三个是相关的,如果我们做一个,我们得到另外两个几乎零额外成本.")

与经理合作以支付积压费用.(不,项目经理不能这样做;他们没有技术深度.不,程序员不能这样做,他们没有概述.)

阐明为什么包名称是这样的,以及为什么数据模型具有这些功能.

找到我们遗漏的东西,并在技术方面重新确定积压的优先级("我们将需要这个额外的冲刺来集成[X],升级[Y]并替换[Z]或者我们永远不会完成这些冲刺. ")

当然.

请记住 - 敏捷并不是一种"给我带来摇滚"的方法.仍有需求,仍然是设计,仍然需要坚实的架构.

当您构建产品或产品线并使用Scrum或其他敏捷方法来管理项目时,其中一个关键思想是开发一个简短的迭代周期,优先处理待完成的任务,确定迭代中的内容A,B,C等建筑师真的有价值.让某人清楚地了解X,Y和Z如何组合在一起可以使您的Scrum迭代更加高效.

敏捷开发并不意味着无政府主义的发展,它仍然需要协调,以便随着时间的推移保持可维护性.

但是......也许瀑布方法论和敏捷方法论之间的最大区别在于,你会在瀑布中找到一个软件架构师PERSON,你可能会在敏捷开发中使用achitect SKILL软件.我的意思是,随着人们更加努力地工作,技能很有可能随着时间的推移而变得更加共享洞穴队,这很好.

当然,软件架构师"领导者"将是保持全局并确保所有构建块一致的人,但他不会是唯一一个随时间推荐的人,因为他的知识将被教导对其他人.

绝对是的,特别是在中型到大型项目上.建筑师通过鸟瞰项目提供技术指导,并负责评估和降低技术风险.开发人员往往关注度较低,而且较少受到高层关注.