开始于：为什么需要构建软件？ (Begin With: Why Do You Need To Build Software?)

There are a many reasons why an organization needs to build and deliver software. Some examples might be:

组织需要构建和交付软件的原因有很多。 一些示例可能是：

• Grow integrated strategic partnerships

  发展综合战略伙伴关系

• Improve internal proprietary processes

  改善内部专有流程

• Quality assurance and business intelligence

  质量保证和商业智能

• Build products and tools that customers will use directly

  构建客户将直接使用的产品和工具

Taking the time to understand the “why” can help you determine how to structure a delivery team and establish long term plans. In many cases an organization may find it has multiple answers to the “why” and this could be a good indicator that a team for each might be a good idea.

花时间了解“为什么”可以帮助您确定如何组建交付团队并制定长期计划。 在许多情况下，一个组织可能会发现它对“为什么”有多个答案，这可以很好地表明每个人的团队都是一个好主意。

创建统一的工作流与功能组 (Create Aligned Work Streams vs Functional Groups)

Before we can dive into the 4 components that make a delivery team successful, we need to address team structure. For years many organizations structured software development teams by the “how” instead of “why”. For example — QA experts and engineers were divided into groups. I’m sure some of the thought process was to build competency within an organization. Unless you are offering those services directly to customers — your goals shouldn’t be building a stellar “QA” or “Engineering” team. You want a high performing “delivery” teams that just happen to be composed of individuals in these roles. Consider objective first, software creation second. Think diversity of perspectives — putting people with different skill-sets and roles together for a common goal will cultivate continuous improvement.

在深入探讨使交付团队成功的4个要素之前，我们需要解决团队的结构。 多年来，许多组织通过“如何”而不是“为什么”来组织软件开发团队。 例如，质量检查专家和工程师被分为几组。 我确信某些思考过程是在组织内部建立能力。 除非您直接向客户提供这些服务，否则您的目标不应是建立一支强大的“ QA”或“工程”团队。 您需要一个高性能的“交付”团队，这些团队恰好由这些角色中的个人组成。 首先考虑目标，然后考虑软件创建。 考虑不同的观点-将具有不同技能和角色的人们聚集在一起以实现一个共同的目标将促进持续的改进。

4个组成部分 (The 4 Components)

I’m going to attempt to describe each component and then give examples of ways a team can implement each one. Understand that every organization and work-stream may be different — so not all may apply.

我将尝试描述每个组件，然后举例说明团队可以实现每个组件的方式。 了解每个组织和工作流程可能都不同，因此并非所有组织和工作流程都适用。

Build is traditionally measured by how well your organization can produce technology that can scale, can be maintained cost effectively, and functions consistently. In addition to these considerations I would also include flexibility. A build team that understands how to work iteratively — applying the correct level of technology & effort to deliver what is necessary is key. The ability to produce quality software in a predictable way is the result of multiple aligned efforts.

传统上，构建是通过您的组织生产可扩展的技术，可以保持成本效益的方法以及一致运行的技术的能力来衡量的。 除了这些考虑之外，我还将包括灵活性。 一支懂得如何迭代工作的构建团队-运用正确的技术水平和精力来交付必要的东西是关键。 以可预见的方式生产高质量软件的能力是多重努力的结果。

Application Portfolio Management & Support: In order to continue building you have to consider what has been built already. One mistake many organizations make is creating dedicated support teams that are not aligned with a work stream. The result is a disenfranchised team and a pile of technology that eats up resources. A team that doesn’t manage its portfolio will also run into serious tech debt issues — ultimately impacting its ability to deliver. Further Reading: (TIME) Tolerate | Invest | Maintain | Eliminate

应用程序组合管理和支持：为了继续构建，您必须考虑已经构建的内容。 许多组织犯的一个错误是创建了不符合工作流程的专门支持团队。 结果是被剥夺了权利的团队和大量消耗资源的技术。 不管理其投资组合的团队也会遇到严重的技术债务问题，最终影响其交付能力。 进一步阅读：( 时间)宽容| 投资 维护| 消除

DevOps: In my mind the greatest contributor to effective delivery is the ability to ship code safely and effortlessly. Thinking back to days when I had to deal with 45 minute builds, complex manual deployment processes, and terrifying testing procedures — this is an easy one in my book. I also believe this is an enabler for organizations with on-prem technology that want to get to the cloud. Further Reading: State Of DevOps (Google)

DevOps：在我看来，有效交付的最大贡献是能够安全，轻松地交付代码。 回想一下我不得不处理45分钟的构建，复杂的手动部署过程以及可怕的测试过程的日子，这在我的书中很简单。 我还相信，这对于希望进入云的具有本地技术的组织来说是一个推动因素。 进一步阅读： DevOps的状态(Google)

Quality Assurance: This requires a role that specializes in regression and user acceptance testing. Some of this can also be automated but nothing replaces an individual with domain knowledge that can find bugs. The level of QA necessary for a work stream is dependent on the level of acceptable risk. Ex — financial or healthcare processing will need more QA that a startup still looking for product market fit. Further Reading: Software Testing Tactics

质量保证：这需要专门从事回归和用户接受度测试的角色。 其中某些功能也可以自动执行，但没有什么可以取代可以发现错误的领域知识来代替个人。 工作流程所需的质量保证级别取决于可接受的风险级别。 举例来说，金融或医疗保健流程将需要更多的质量保证，而初创公司仍在寻找适合市场的产品。 进一步阅读： 软件测试策略

Software Development: An obvious component of build — a good development team is critical to executing. Software craftsmanship concepts such as TDD and SOLID are game changers when attempting to deliver high quality software quickly. Further Reading: SOLID | TDD

软件开发：构建的一个显而易见的组成部分-一个好的开发团队对于执行至关重要。 尝试快速交付高质量软件时，TDD和SOLID等软件Craft.io概念将改变游戏规则。 进一步阅读： SOLID | TDD

学习 (Learn)

You must inform your build effort, otherwise you will produce technology that is of little value ( meaningless). You do this by growing the collective knowledge of the team. It’s important to understand that one person or one role isn’t solely responsible for this on well functioning teams. Every member should have the freedom to contribute.

您必须告知您的构建工作，否则您将产生的技术价值很小( 毫无意义 )。 您可以通过增进团队的集体知识来做到这一点。 重要的是要了解，一个人或一个角色并不能完全由运作良好的团队负责。 每个成员都应有贡献的自由。

User Experience Research: This role is an absolute must for product focused work streams. Creation of user personas, qualitative & quantitative research, and structured user interviews are all important if an organization wishes to build products that provide real value. This role also places a high emphasis on creating value by understanding the behaviors and needs of users. Further Reading: User Experience Definitions

用户体验研究：此角色对于以产品为中心的工作流是绝对必须的。 如果组织希望开发能够提供真正价值的产品，则创建用户角色，进行定性和定量研究以及进行结构化的用户访谈都非常重要。 该角色还高度重视通过了解用户的行为和需求来创造价值。 进一步阅读： 用户体验定义

Business Analysis: While UX focuses on users, BA roles tend to focus on business and process. The type of work stream again determines the importance of this role on the team. Business analysts also tend to retain and build domain knowledge. This can be critical as well if your work stream is heavy on complex business processes. Practices such as process mapping and requirements gathering are extremely valuable when dealing with complex workflows and business needs. Further Reading: 5 Whys | MoSCoW

业务分析： UX侧重于用户，而BA角色则侧重于业务和流程。 工作流的类型再次确定了此角色在团队中的重要性。 业务分析师还倾向于保留和积累领域知识。 如果您的工作流程集中在复杂的业务流程上，那么这也很关键。 处理复杂的工作流和业务需求时，诸如流程映射和需求收集之类的实践非常有价值。 进一步阅读： 5个原因 | 莫斯科

Technical Analysis & Design: Commonly misunderstood or ignored this role is a must have on teams that maintain and enhance large systems or a large number of applications. Sometimes domain knowledge lives within code and the only way to re-discover requires a deep dive into the code. In most cases this needs to be an experienced developer who can translate code into requirements (or at minimum technical specifications). Some organizations attempt to avoid this by producing large volumes of documentation — in many cases it’s not a viable solution. Further Reading: Using FDD Features

技术分析与设计：通常，对于维护和增强大型系统或大量应用程序的团队来说，此角色是必不可少的。 有时，领域知识存在于代码中，而重新发现的唯一方法需要深入研究代码。 在大多数情况下，这需要有经验的开发人员，他们可以将代码转换为需求(或以最低的技术规范)。 一些组织试图通过生成大量文档来避免这种情况-在许多情况下，这不是可行的解决方案。 进一步阅读： 使用FDD功能

促进 (Promote)

Once you build something you need to ensure that its value is understood by stakeholders and users. I consider this effort one of the 4 pillars because without it you don’t receive feedback or traction. Unused software is meaningless software — even if it “could” offer value. There is strong overlap in this area with general sales and marketing but this is outside the scope of “software delivery”.

一旦构建完成，就需要确保利益相关者和用户理解其价值。 我认为这项工作是四大Struts之一，因为没有它，您将不会获得反馈或牵引力。 未使用的软件是没有意义的软件，即使它“可以”提供价值。 该领域与一般的销售和市场营销有很大的重叠，但这超出了“软件交付”的范围。

Demos: One way you can promote internally is via “Demo Days”. Showing new functionality to stakeholders and team members creates conversations which generates internal feedback loops. This ensures that everyone understands the value. Also, this also offers an opportunity to team members who wish to build communication and speaking skills. Further Reading: How to Give a Great Agile/Scrum Sprint Demo

演示 ：内部推广的一种方法是通过“演示日”。 向涉众和团队成员展示新功能会创建对话，从而产生内部反馈循环。 这样可以确保每个人都了解其价值。 同样，这也为希望建立交流和口语技能的团队成员提供了机会。 进一步阅读： 如何制作出色的敏捷/ Scrum Sprint演示

Roadmaps: Communicating the direction of the team to the organization is important. Hopefully it can provide a source of excitement and inspiration for the entire organization. A well communicated roadmap in conjunction with a good company culture should result in aligned efforts and a shared vision. Further Reading: Department Of Product: Roadmaps

路线图 ：沟通团队对组织的方向很重要。 希望它可以为整个组织带来兴奋和灵感。 沟通良好的路线图以及良好的公司文化应导致一致的努力和共同的愿景。 进一步的阅读： 产品部：路线图

Customer Experience: Ensuring that customers can easily understand and utilize features the team has created — in conjunction with the offering as a whole ensures that engagement can scale as the product becomes more complex (and/or integrated). I consider this “promotion” because creating a good customer experience is a form of promoting the underlying value provided by the platform. Further Reading: User Experience vs. Customer Experience

客户体验 ：确保客户可以轻松理解和利用团队已创建的功能-与整个产品相结合，可确保随着产品变得更加复杂(和/或集成)而扩大参与度。 我认为这是“促销”，因为创造良好的客户体验是提升平台提供的潜在价值的一种形式。 进一步阅读： 用户体验与客户体验

核心 (Core)

Now we get to the really fun part. Putting it all together. While the other 3 components can vary based on organizational structure and work stream needs — these items are non-negotiable if you wish to successfully deliver meaningful software.

现在我们进入真正有趣的部分。 全部放在一起。 尽管其他3个组件会根据组织结构和工作流需求而有所不同-如果您希望成功交付有意义的软件，则这些项目是不可商议的。

Ownership: Without strategic direction a team is very likely to focus on small items that don’t line up with larger objectives (although I do think it’s possible for teams to become aligned — a topic for another time). Decision makers need to be responsible for collecting information from all 3 components, weave in considerations from leadership, and set a course. Among the many decisions to be made lies the most critical — platform and feature prioritization. Further Reading: A Stakeholder Proxy for Agile Teams

拥有权：没有战略指导，团队很可能会将精力集中在与更大目标不符的小项目上(尽管我确实认为团队有可能结成联盟，这是下一个话题)。 决策者需要负责从所有三个组成部分中收集信息，编织领导层的考虑因素并制定路线。 最重要的决定之一就是平台和功能的优先级。 进一步阅读： 敏捷团队的利益相关者代理

Continuous Improvement: A team that wants to deliver meaningful software must strive to be better on both a team and individual level. The only way this works however is if the team defines and measures continuous improvement goals on its own. An autonomous team that has the freedom to test (and fail) in an effort to improve will produce consistently better results long term. Further Reading: RetroMat

持续改进：想要交付有意义的软件的团队必须努力在团队和个人层面上都变得更好。 但是，唯一可行的方法是团队自行定义和衡量持续改进目标。 具有测试(和失败)自由度以进行改进的自主团队将长期产生持续更好的结果。 相关阅读： RetroMat

Work Agreements: Informed by continuous improvement, this can include work visualization, code quality practices, ceremonies, definition of done, and other “contracts” among team members. The importance of mutually agreed upon expectations is it removes frustration from the day to day. A good example of this is user stories. A great format for collecting requirements and managing the work — but the real value is its ability to transfer knowledge among multiple team members and roles in a well understood format. Add the ability to visualize priority and progress and the team finds itself aligned. Also keep in mind, while the agreements may be rigid in definition your continuous improvement efforts should allow for them to change easily when necessary. Further Reading: Agile Meetings — Goals and Benefits | Kanban vs. Scrum

工作协议：通过不断改进，可以包括工作可视化，代码质量实践，仪式，完成的定义以及团队成员之间的其他“合同”。 共同商定的期望的重要性在于，它消除了日常的挫败感。 用户故事就是一个很好的例子。 收集需求和管理工作的一种很好的格式，但是真正的价值在于它以公认的格式在多个团队成员和角色之间传递知识的能力。 添加可视化优先级和进度的功能，团队将保持一致。 还请记住，尽管协议在定义上​​可能很严格，但您的持续改进工作应允许它们在必要时轻松更改。 进一步阅读： 敏捷会议—目标和收益 | 看板与Scrum

If you want to improve your ability to contribute to and drive the delivery of meaningful software I’d encourage you to follow along on this journey — sign up for my weekly newsletter.

如果您想提高自己的能力，以推动并推动有意义的软件的交付，我鼓励您跟随这一旅程— 注册我的每周时事通讯 。

Originally published at https://7samurai.dev on August 24, 2020.

最初于 2020年8月24日 发布在 https://7samurai.dev 。