First of all: Scrum team is self organized. That means that technical management roles are not so much expressed. Yes, team cans elect/invite a member for a role. But in this hiring role also should be delegating to the team. Yeah..it is not really.Besides team's activity are strongest in meeting and sprint parts, mainly.Technical architecture provides solutions of the level of epics and, at least, requires building road map, approving technologies, feed back to stakeholders and other specific operations are our of topic scope. Besides, technical architects acts in corporate development interests of company, especially for keeping DRY and other principles of solutions reuse,quality and so on.Of coarse sprints can be and must be interrelated in multi team company, that requires also arrangement on leadership level. In these aspects, architect is on behalf of stakeholders, and, furthermore, a technical elements, constraints, pattern, technologies, which are the subject for implementation, are a right section in user story. Basically, when necessary, architect cans write code in a sprint frames if it is in interests of business (this strongly depends on leadership code in a concrete company, I do not see here nothing to be out of range). But, defined role of architect is technical solutions on behalf of stakeholders to conduct business to technical definitions translation and technical guideline control
我认为没有必要，因为由 SCRUM 最初的共振峰 Dr Jeff Sutherland 和 Ken Schwaber 编写的 SCRUM 指南没有提到这一点。
I dont think there is the need as the SCRUM guide written by the original formants of SCRUM Dr Jeff Sutherland and Ken Schwaber doesnt mention the need for one.
We've been practising Scrum successfully for 1 year and what we've experienced is that there are two things that have to be balanced: -System Architecture is an important "counterweight" in a purely feature driven development environment. Strategic and mid-term planning on technical level has to be done explicitely as Product Owners focus on the next features they want to be implemented (which is of course ok for their part) -On the other hand being truly agile means that -System Architects should not sit in ivory towers (as mentioned in several previous posts) and design things that work in theory only -Knowledge should be distributed so that every team has sufficient architectural skills
Our solution was the following (we are working in a multi-team environment): We created a virtual team lead by the Lead Architect (who is not part of a Scrum team). Each team decides for each issue that has to be discussed which members want to take part in the discussion. The team makes a common decision. If additional work is necessary this is either done via a new user story or if it is small outside of Scrum. The team members who comitted themselves to the decision are responsible to communicate the decision and control its execution within their teams.
‘Architect’ was a term software stole from the construction industry with the intentions to describe someone who oversaw the project as a whole. An architect in the construction industry is someone who consults Structural Engineers on the appearance and ‘human interface’ of the project. A closer parallel can be drawn between the construction “architect” and the “UX designer” of a software project. The term that I believe more closely describes what a Software Architect does, is Systems Engineer.'
So what is the role of software architecture in agile development? To understand this, it is important to understand the principles of agile software development. These principles can be found in the Manifesto for Agile Software Development here http://agilemanifesto.org
Individuals and interactions over processes and tools
My role as architect in Scrum includes the following.
Technical spikes -- proofs of concept -- how will we do that. ("It would be simpler if you'd simply using the SMTP library directly, it already wraps the existing SMTP libraries; writing your own wrapper around our wrapper doesn't help much. We can add the method you want.")
Coordination among the developers to fit the intended architecture. ("Ummm... why are you using your own properties file?"
Working with users to prioritize the backlog appropriately. ("These three are related, if we do one, we get the other two at almost zero extra cost.")
Working with managers to cost the backlog. (No, a project manager can't do this; they don't have the technical depth. No, the programmers can't do this, they don't have the overview.)
Articulating why the package names are that way, and why the data model has those features.
Finding the things we're missing and reprioritizing the backlog on technical grounds ("We're going to need this additional sprint to integrate [X], upgrade [Y] and replace [Z] or we'll never get those sprints done.")
Remember - agile isn't a 'bring me a rock' approach. There are still requirements, still a design and still a need for a solid architecture.
When you are building a product or product line and employing Scrum or some other agile approach to managing your project, one of the key ideas is developing a short iteration cycle, prioritizing the backlog of tasks to accomplish, determining what is going to be in iteration A, B, C, etc. There is where an architect can really be valuable. Having someone with a clear idea of how X, Y and Z all will fit together can make your Scrum iterations that much more productive.
Agile development does not means anarchist development, it still need to be coordonate in order to stay maintanable over time.
But... Maybe the biggest difference between waterfall methodologis and agile methodologies, is that where you'll find a software achitect PERSON in the waterfall, you'll probably software achitect SKILL in agile developpments. I mean, as people are working more tidely toeghether, there is a high chance that skills become over time more shared accros the hole team, which is good.
Of course the software architect "leader" will be the one that keep the big picture in place and ensure that all the building blocks are consistent, but he won't be the only one to refer over the time, as his knowledge will be teach to the others.
Absolutely yes, especially on medium to large projects. An architect provides technical direction by having a bird's eye view of the project and is responsible for assessing and mitigating technical risk. Developers tend to have a narrower focus and are less exposed to high level concerns.
The development/project process that you have mentioned are for building the things that the architect as designed.
So the often used analogy, the architect designs and plans the - city, the roads, the buildings.
The developers build the city, the roads, the buildings.
The developers can use what ever project managment system they need to get the building up, cars on the road and the city functioning.
Just as building architects are on hand to oversee the building with the engineers, so too should the software architect be on hand to oversee the development process.
Both roles Architect and Developer are related - but can follow different process to achive their own work programme.
Absolutely - an architect is desired and required in a scrum team. Perhaps you'll not hear that from scrum/agile evangelists, trainers etc. but any experienced product owner will tell you that. An architect's role in scrum is very important.
I would say that there certainly is. Even though the focus in agile is on developers being free to deign their own code there is still a need for an overall program design at a higher level than an individual developer would be working.
However... Agile is best for small projects, and specialized Architects normally are more useful in large projects.
The way I think with would work well, is if the Architect lays down the over all road-map and defines the necessary modules along with team leaders in a Scrum fashion. However then the Team leaders and their Scrum teams do the the actual development.
Even in an Agile methodology, which may not have a strict hierarchy, programmers are not going to be equal. You will have seasoned campaigners, beginners, those who know the codebase and the problem domain backwards and combinations of the above.
I think that although there may be not "formal" architecture on a truly agile project, there are always architectural concerns that need to be addressed and it is generally the more experienced team members that will have the knowledge to address some of these things.
And also keep in mind that the internal project method may be separate from the pay-grade - so a title may largely be ignored "on the job" so to speak.
发布评论
评论（15）
首先：Scrum团队是自组织的。 这意味着技术管理角色没有得到太多体现。 是的，团队可以选择/邀请成员担任某个角色。 但在这个招聘中，角色也应该委托给团队。 是的..事实并非如此。除了团队的活动主要在会议和冲刺部分最强之外。技术架构提供了史诗级的解决方案，至少需要构建路线图、批准技术、反馈给利益相关者和其他特定的操作是我们的主题范围。 此外，技术架构师的行为符合公司的发展利益，特别是保持DRY和解决方案重用、质量等其他原则。在多团队公司中，粗冲刺可以而且必须是相互关联的，这也需要领导层的安排。 在这些方面，架构师代表利益相关者，此外，作为实现主题的技术元素、约束、模式、技术是用户故事中的正确部分。 基本上，在必要时，如果符合业务利益，架构师可以在冲刺框架中编写代码（这很大程度上取决于具体公司的领导代码，我认为这里没有什么超出范围的）。 但是，架构师的定义角色是代表利益相关者的技术解决方案，进行业务到技术定义的转换和技术指南控制
First of all: Scrum team is self organized. That means that technical management roles are not so much expressed. Yes, team cans elect/invite a member for a role. But in this hiring role also should be delegating to the team. Yeah..it is not really.Besides team's activity are strongest in meeting and sprint parts, mainly.Technical architecture provides solutions of the level of epics and, at least, requires building road map, approving technologies, feed back to stakeholders and other specific operations are our of topic scope. Besides, technical architects acts in corporate development interests of company, especially for keeping DRY and other principles of solutions reuse,quality and so on.Of coarse sprints can be and must be interrelated in multi team company, that requires also arrangement on leadership level. In these aspects, architect is on behalf of stakeholders, and, furthermore, a technical elements, constraints, pattern, technologies, which are the subject for implementation, are a right section in user story. Basically, when necessary, architect cans write code in a sprint frames if it is in interests of business (this strongly depends on leadership code in a concrete company, I do not see here nothing to be out of range). But, defined role of architect is technical solutions on behalf of stakeholders to conduct business to technical definitions translation and technical guideline control
我认为没有必要，因为由 SCRUM 最初的共振峰 Dr Jeff Sutherland 和 Ken Schwaber 编写的 SCRUM 指南没有提到这一点。
I dont think there is the need as the SCRUM guide written by the original formants of SCRUM Dr Jeff Sutherland and Ken Schwaber doesnt mention the need for one.
我们已经成功实践 Scrum 一年了，我们的经验是有两件事必须平衡：
- 系统架构是纯功能驱动开发环境中的重要“平衡点”。 技术层面的战略和中期规划必须
当产品负责人专注于他们想要实现的下一个功能时明确完成（这对他们来说当然是可以的）
-另一方面，真正敏捷意味着
-系统架构师不应该坐在象牙塔里（如之前的几篇文章中提到的）并设计仅在理论上有效的东西
-知识应该分布，以便每个团队都有足够的架构技能
我们的解决方案如下（我们在多团队环境中工作）：
我们创建了一个由首席架构师（不属于 Scrum 团队）领导的虚拟团队。 每个团队针对必须讨论的每个问题做出决定
哪些成员想要参加讨论。 团队做出共同决定。 如果需要额外的工作，可以通过新的用户故事来完成
或者如果它在 Scrum 之外很小。 做出决定的团队成员有责任传达该决定
并在团队内控制其执行。
We've been practising Scrum successfully for 1 year and what we've experienced is that there are two things that have to be balanced:
-System Architecture is an important "counterweight" in a purely feature driven development environment. Strategic and mid-term planning on technical level has to be
done explicitely as Product Owners focus on the next features they want to be implemented (which is of course ok for their part)
-On the other hand being truly agile means that
-System Architects should not sit in ivory towers (as mentioned in several previous posts) and design things that work in theory only
-Knowledge should be distributed so that every team has sufficient architectural skills
Our solution was the following (we are working in a multi-team environment):
We created a virtual team lead by the Lead Architect (who is not part of a Scrum team). Each team decides for each issue that has to be discussed
which members want to take part in the discussion. The team makes a common decision. If additional work is necessary this is either done via a new user story
or if it is small outside of Scrum. The team members who comitted themselves to the decision are responsible to communicate the decision
and control its execution within their teams.
绝对地。 无论如何，没有理由必须预先完成架构。
Absolutely. No reason the architecture has to be done all up front anyway.
是的，非常如此，
“建筑师”是一个从建筑行业偷来的软件术语，旨在描述监督整个项目的人。 建筑行业的建筑师是向结构工程师咨询项目的外观和“人机界面”的人。 软件项目的构建“架构师”和“UX 设计师”之间可以有更紧密的相似之处。 我认为更贴切地描述软件架构师的工作的术语是系统工程师。
那么软件架构在敏捷开发中的作用是什么？ 要理解这一点，了解敏捷软件开发的原则很重要。 这些原则可以在《敏捷软件开发宣言》中找到 http://agilemanifesto.org
个体和交互流程和工具
工作软件高于全面文档
客户协作高于合同谈判
响应变更而不是遵循计划
更多信息请参见：http://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/
Yes very much so
‘Architect’ was a term software stole from the construction industry with the intentions to describe someone who oversaw the project as a whole. An architect in the construction industry is someone who consults Structural Engineers on the appearance and ‘human interface’ of the project. A closer parallel can be drawn between the construction “architect” and the “UX designer” of a software project. The term that I believe more closely describes what a Software Architect does, is Systems Engineer.'
So what is the role of software architecture in agile development? To understand this, it is important to understand the principles of agile software development. These principles can be found in the Manifesto for Agile Software Development here http://agilemanifesto.org
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
More information here: http://carlospliego.com/2016/10/08/agileSoftwareDevelopmentAndArchitecture/
我作为 Scrum 架构师的角色包括以下内容。
技术高峰——概念证明——我们将如何做到这一点。 （“如果您直接使用 SMTP 库，会更简单，它已经包装了现有的 SMTP 库；围绕我们的包装器编写您自己的包装器并没有多大帮助。我们可以添加您想要的方法。”）
开发人员之间的协调以适应预期的架构。 （“嗯......你为什么使用你自己的属性文件？”
工作与用户一起适当地确定待办事项的优先级（“这三个是相关的，如果我们这样做，我们就能以几乎零额外成本获得其他两个。”）与用户
与经理合作以减少积压的成本。（不，项目经理不能这样做；他们没有不，程序员不能这样做，他们没有概述。）
阐明为什么包名称是这样的，以及为什么数据模型具有这些功能。
找到我们遗漏的东西，并根据技术理由重新确定待办事项的优先顺序（“我们将需要这个额外的冲刺来集成 [X]、升级 [Y] 和替换 [Z]，否则我们永远不会得到这些冲刺已完成。”）
My role as architect in Scrum includes the following.
Technical spikes -- proofs of concept -- how will we do that. ("It would be simpler if you'd simply using the SMTP library directly, it already wraps the existing SMTP libraries; writing your own wrapper around our wrapper doesn't help much. We can add the method you want.")
Coordination among the developers to fit the intended architecture. ("Ummm... why are you using your own properties file?"
Working with users to prioritize the backlog appropriately. ("These three are related, if we do one, we get the other two at almost zero extra cost.")
Working with managers to cost the backlog. (No, a project manager can't do this; they don't have the technical depth. No, the programmers can't do this, they don't have the overview.)
Articulating why the package names are that way, and why the data model has those features.
Finding the things we're missing and reprioritizing the backlog on technical grounds ("We're going to need this additional sprint to integrate [X], upgrade [Y] and replace [Z] or we'll never get those sprints done.")
当然。
请记住 - 敏捷并不是一种“给我一块石头”的方法。 仍然存在需求，仍然存在设计，仍然需要可靠的架构。
当您构建产品或产品线并采用 Scrum 或其他敏捷方法来管理项目时，关键思想之一是开发一个短迭代周期，确定要完成的积压任务的优先级，确定迭代中的内容A、B、C 等等。这就是建筑师真正有价值的地方。 让某人清楚地了解 X、Y 和 Z 如何组合在一起可以使您的 Scrum 迭代更加高效。
Sure.
Remember - agile isn't a 'bring me a rock' approach. There are still requirements, still a design and still a need for a solid architecture.
When you are building a product or product line and employing Scrum or some other agile approach to managing your project, one of the key ideas is developing a short iteration cycle, prioritizing the backlog of tasks to accomplish, determining what is going to be in iteration A, B, C, etc. There is where an architect can really be valuable. Having someone with a clear idea of how X, Y and Z all will fit together can make your Scrum iterations that much more productive.
敏捷开发并不意味着无政府主义开发，它仍然需要协调才能随着时间的推移保持可维护性。
但是……也许瀑布方法论和敏捷方法论之间最大的区别是，当你在瀑布中找到软件架构师时，你可能会掌握敏捷开发中的软件架构师技能。 我的意思是，随着人们更加紧密地合作，随着时间的推移，整个团队的技能很有可能会变得更加共享，这是件好事。
当然，软件架构师“领导者”将是保持大局并确保所有构建块保持一致的人，但他不会是唯一一个随着时间的推移而参考的人，因为他的知识将被教授给其他人。
Agile development does not means anarchist development, it still need to be coordonate in order to stay maintanable over time.
But... Maybe the biggest difference between waterfall methodologis and agile methodologies, is that where you'll find a software achitect PERSON in the waterfall, you'll probably software achitect SKILL in agile developpments. I mean, as people are working more tidely toeghether, there is a high chance that skills become over time more shared accros the hole team, which is good.
Of course the software architect "leader" will be the one that keep the big picture in place and ensure that all the building blocks are consistent, but he won't be the only one to refer over the time, as his knowledge will be teach to the others.
绝对是的，尤其是在中型到大型项目中。 建筑师通过鸟瞰项目来提供技术指导，并负责评估和减轻技术风险。 开发人员的关注范围往往较小，并且较少受到高层关注。
Absolutely yes, especially on medium to large projects. An architect provides technical direction by having a bird's eye view of the project and is responsible for assessing and mitigating technical risk. Developers tend to have a narrower focus and are less exposed to high level concerns.
完全。
您提到的开发/项目过程是为了构建架构师设计的东西。
所以经常使用的比喻是，建筑师设计和规划——城市、道路、建筑物。
开发商建造城市、道路和建筑物。
开发商可以使用他们所需的任何项目管理系统来建设建筑、道路上的汽车和城市的运转。
正如建筑建筑师与工程师一起监督建筑一样，软件架构师也应该在场监督开发过程。
架构师和开发人员这两个角色是相关的 - 但可以遵循不同的流程来实现自己的工作计划。
Totally.
The development/project process that you have mentioned are for building the things that the architect as designed.
So the often used analogy, the architect designs and plans the - city, the roads, the buildings.
The developers build the city, the roads, the buildings.
The developers can use what ever project managment system they need to get the building up, cars on the road and the city functioning.
Just as building architects are on hand to oversee the building with the engineers, so too should the software architect be on hand to oversee the development process.
Both roles Architect and Developer are related - but can follow different process to achive their own work programme.
绝对 - Scrum 团队需要并需要架构师。 也许您不会从 Scrum/敏捷传播者、培训师等那里听到这一点，但任何经验丰富的产品负责人都会告诉您这一点。 架构师在 Scrum 中的角色非常重要。
Absolutely - an architect is desired and required in a scrum team. Perhaps you'll not hear that from scrum/agile evangelists, trainers etc. but any experienced product owner will tell you that. An architect's role in scrum is very important.
我想说肯定有。 尽管敏捷的重点是开发人员可以自由地设计自己的代码，但仍然需要比单个开发人员工作更高级别的整体程序设计。
I would say that there certainly is. Even though the focus in agile is on developers being free to deign their own code there is still a need for an overall program design at a higher level than an individual developer would be working.
然而......敏捷最适合小型项目，而专业架构师通常在大型项目中更有用。
我认为效果很好的方法是，架构师以 Scrum 方式制定总体路线图并与团队领导者一起定义必要的模块。 然而，随后团队领导者和他们的 Scrum 团队会进行实际的开发。
有点像两阶段的 Scrum。
However... Agile is best for small projects, and specialized Architects normally are more useful in large projects.
The way I think with would work well, is if the Architect lays down the over all road-map and defines the necessary modules along with team leaders in a Scrum fashion. However then the Team leaders and their Scrum teams do the the actual development.
Kind of a two-staged Scrum.
我认为这更多的是一个技能问题而不是方法问题。 所以，是的，即使他有这个头衔，他也可能有一个角色。
I would think that this is more a skills issue than an approach issue. So yes he may have a role even if he has that title.
即使在可能没有严格层次结构的敏捷方法中，程序员也不会是平等的。 您将拥有经验丰富的活动家、初学者、了解代码库和问题领域以及上述内容的组合的人。
我认为，尽管真正的敏捷项目可能没有“正式”的架构，但总是存在需要解决的架构问题，并且通常是更有经验的团队成员拥有解决其中一些问题的知识。
还要记住，内部项目方法可能与薪资等级是分开的——所以可以说，“在工作中”头衔可能会在很大程度上被忽略。
Even in an Agile methodology, which may not have a strict hierarchy, programmers are not going to be equal. You will have seasoned campaigners, beginners, those who know the codebase and the problem domain backwards and combinations of the above.
I think that although there may be not "formal" architecture on a truly agile project, there are always architectural concerns that need to be addressed and it is generally the more experienced team members that will have the knowledge to address some of these things.
And also keep in mind that the internal project method may be separate from the pay-grade - so a title may largely be ignored "on the job" so to speak.