Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translate learning path into Chinese : project leader #818

Closed
wants to merge 15 commits into from
Closed

Translate learning path into Chinese : project leader #818

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
19d477a
Create _index.zh.md
node Jun 19, 2024
a56df54
Update 01.md to translate into Chinese
node Jun 20, 2024
5ed6d96
translate 01 into Chinese
Jun 20, 2024
0abf3f1
Merge branch 'translate-learning-path-zh' of github.com:node/innersou…
node Jun 20, 2024
74608d1
Translate 01 into Chinese
node Jun 20, 2024
9b898d6
Merge branch 'translate-learning-path-zh' of github.com:node/innersou…
node Jun 20, 2024
043e80f
clear file
node Jun 20, 2024
4f1043a
Merge branch 'InnerSourceCommons:master' into translate-learning-path-zh
node Jun 20, 2024
adaf9e7
Merge branch 'InnerSourceCommons:master' into translate-learning-path-zh
node Jul 4, 2024
08a3ceb
Merge branch 'InnerSourceCommons:master' into translate-learning-path-zh
node Jul 9, 2024
ed447b3
Create 02.zh.md
node Jul 11, 2024
caa53fc
Create 06.zh.md
node Jul 11, 2024
cc1390f
Create 03.zh.md
node Jul 11, 2024
b6faa5d
Create 04.zh.md
node Jul 11, 2024
387fb7c
Create 05.zh.md
node Jul 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/en/learn/learning-path/project-leader/01.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,4 +71,4 @@ complexity of modifications in that approach depends on the maturity of
the organization and the maintainability/modularity of the code
produced.</p>
</div>
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
38 changes: 38 additions & 0 deletions content/en/learn/learning-path/project-leader/01.zh.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
---
title: 项目负责人与 InnerSource
contributors:
- name: Sebastian Spier
url: https://github.com/spier
- name: rrrutledge
url: https://github.com/rrrutledge
- name: Laura
url: https://github.com/marshmallowrobot
- name: Isabel Drost-Fromm
url: https://github.com/MaineC
image: images/learn/LP-article-default.png
featured: true
weight: 1
youtubeCode: ""
---
<div class="paragraph">
<p>完成本部分后，你将更好地了解 InnerSource 如何加快产品开发；我们还将介绍其与敏捷开发最佳实践的关系。</p>
</div>
<div class="paragraph">
<p>为了实现敏捷性，组织努力建立自治团队。然而，在一个复杂、相互关联的世界中，某些依赖性是不可避免的。
InnerSource
<a href="https://innersourcecommons.org/learn/learning-path/introduction/02/">提供了一种替代</a> "等待"、"建立变通办法 "和 "升级 "的方法： 需要修改依赖关系的团队可以伸出援手。
InnerSource 促进了跨团队协作。它注重书面交流，即使在远程模式下也非常适合。</p>
</div>
<div class="paragraph">
<p>在本节中，你将了解到敏捷开发和 InnerSource 使用类似的术语甚至技术，但在细节上却有很大不同。了解两者在文化和工具使用目的上的差异，将使你受益匪浅，而不是陷入常见的误解。</p>
</div>
<div class="paragraph">
<p>你将了解 InnerSource 对能力规划的影响。此外，InnerSource 没有免费的午餐——托管团队需要时间来指导贡献者。我们还将探讨 InnerSource 带来的额外谈判可能性——保持 "投入与收益 "之间的平衡。</p>
</div>
<div class="paragraph">
<p>让我们从一个简单的例子开始。想象一下，你正在开发一款新的可爱风音乐APP。为了了解用户与APP的交互情况，你开始收集一些交互日志。随着时间的推移，你在分析这些日志时会进行更深入的挖掘，并将学到的知识反馈到开发过程。现在，想象一下另一个将内容引入你的APP的团队也有一些需求——他们可能希望根据内容创作者接触到的用户数量来奖励他们。因此，他们也开始使用你收集的日志。但他们需要一些额外的分析步骤，而这是你一开始所没有想到的。他们现在面临着一个挑战：是建立一个变通办法，还是通过你的积压工作来优先处理他们的请求。有了 InnerSource，他们就有了第三种选择： 在你的帮助下自己进行更改。当然，这可能会比你自己修改要慢，但这仍然比等待你进行修改要快。</p>
</div>
<div class="paragraph">
<p>在理想的 InnerSource 组织中，你可以进一步扩大规模： 还记得上次必须在整个平台上进行横向关注点修改吗？如果采用“将其放入每个团队的Backlog”的方式，往往会感觉时间拖得很长；另一方面，它实质上是为这些团队提供一个实现修改的补丁，这会大大加快速度。在这种方法中，修改的复杂程度取决于组织的成熟度和代码的可维护性/模块化程度。</p>
</div>
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
147 changes: 147 additions & 0 deletions content/en/learn/learning-path/project-leader/02.zh.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,147 @@
---
title: InnerSource 与敏捷
contributors:
- name: Sebastian Spier
url: https://github.com/spier
- name: rrrutledge
url: https://github.com/rrrutledge
- name: Laura
url: https://github.com/marshmallowrobot
- name: Isabel Drost-Fromm
url: https://github.com/MaineC
image: images/learn/LP-article-default.png
featured: false
weight: 2
youtubeCode: ""
---
<div class="paragraph">
<p>你希望改进产品，更快地将其交付给客户，并让利益相关者满意。InnerSource 可帮助你的团队在高度互联的世界中实现价值并保持自主性。</p>
</div>
<div class="sect2">
<h3 id="_autonomous_teams_in_an_interconnected_world">互联世界中的自治团队</h3>
<div class="paragraph">
<p>组织试图快速向客户交付价值。一个常见的延迟原因是交付过程中的依赖关系。因此，组织更喜欢跨职能团队，涵盖客户沟通、设计、实施、测试和运营，从而消除昂贵的交接。为了实现高绩效，团队消除浪费并重复使用已有组件。从团队的角度来看，每个重复使用的组件都会给该团队增加一个其无法控制的依赖关系。这种优化的负面影响很明显：如果一个团队需要更改所使用的组件，则该团队依赖于另一个团队。为了能够实施这些计划，通常会安排冗长的路线图讨论，有时需要在全球范围内优化详细的优先级。在复杂的情况下以及在大型组织中，这会导致需要增加适应不断变化的业务需求的时间。对于非常受欢迎的核心组件，通常会收到非常多的请求，以至于一个核心组件团队无法实施对所有请求的响应。</p>
</div>
<div class="paragraph">
<p>在传统组织中只有
<a href="https://innersourcecommons.org/learn/learning-path/introduction/02/">两种方式来更改依赖</a>：</p>
</div>
<div class="ulist">
<ul>
<li>
<p>提交功能请求/错误报告，然后等待其他团队确定变更的优先级并实施。</p>
</li>
<li>
<p>实现一个解决方法来避免错误或在本地提供所需的功能。</p>
</li>
</ul>
</div>
<div class="paragraph">
<p>如果这些方案都不成功，问题通常会升级，由更高层级来决定。</p>
</div>
<div class="paragraph">
<p>这两种解决方案都不是特别令人满意。从开源的视角来看，有一个明显的解决方案：依赖组件的团队成为贡献者，并向该组件团队提供帮助。</p>
</div>
<div class="paragraph">
<p>现在你可能会有这样的疑问：“这样做难道不会引起很大混乱，让人们会随意修改其他团队的代码库吗？”InnerSource 提供了一套角色和流程，使原本可能导致混乱的情况变得更加清晰：</p>
</div>
<div class="ulist">
<ul>
<li>
<p>每个 InnerSource 项目都有一组职责明确的受信任提交者，他们的职责不仅仅是简单地审查代码，还要制定贡献规则。</p>
</li>
<li>
<p>贡献以有组织的方式进行：</p>
<div class="ulist">
<ul>
<li>
<p>尽早交流贡献意向，确保贡献符合项目的愿景和范围。</p>
</li>
<li>
<p>尽早分享进展，项目主办团队就有机会指导贡献者，引导他们实现理想的设计和架构；这样就能避免在后期因拒绝贡献而产生的挫败感。</p>
</li>
<li>
<p>决策和重要沟通异步进行，以便能够解决不同团队中人员的不同会议安排。因此，贡献团队获得了修复上游组件的自主权，而又不会牺牲所贡献组件的质量。</p>
</li>
</ul>
</div>
</li>
</ul>
</div>
<div class="paragraph">
<p>此外，InnerSource 还为团队提供最佳实践，让团队在远程文化中轻松工作。</p>
</div>
</div>
<div class="sect2">
<h3 id="_advantages_of_an_innersource_approach">InnerSource 方法的优点</h3>
<div class="paragraph">
<p>InnerSource 鼓励团队之间相互协作，而不是各自为政。就像在开源领域一样，这意味着要站在巨人的肩膀上：InnerSource 鼓励复用，而不是在本地重复构建每个组件。它提供了一条明确的途径，支持上游团队修复错误和实现功能，从而降低了重复使用的成本。</p>
</div>
<div class="paragraph">
<p>就像在开源领域一样，InnerSource 培养了一种联合力量的思维： 所有业务部门和产品团队所需的基础组件都可以共同构建。因此，百舸争流：组织中某个部门的创新可以为整个公司创造效益。有了熟悉 InnerSource 的团队，所有团队都可以分担推进此类创新的重任，并从中受益，依赖于由此产生的组件和服务。</p>
</div>
<div class="paragraph">
<p>InnerSource 为你的团队提供了主动性和工具，以解决阻碍向客户交付功能的问题。如果方法得当，核心组件和服务的维护工作可以由一个“虚拟 InnerSource 团队”以结构合理的方式共享，该团队的规模要大于任何特定的产品团队。</p>
</div>
<div class="paragraph">
<p>在高级设置中，相关人员理解贡献者开发较简单功能的价值，这些功能可能不会直接惠及他们的客户-——但前提条件是，这可以让托管团队腾出时间来开发贡献者有业务需求的更复杂的变更。</p>
</div>
</div>
<div class="sect2">
<h3 id="_does_innersource_replace_agile">InnerSource 会取代敏捷吗？</h3>
<div class="paragraph">
<p>直接答案： 完全不是。恰恰相反，两者相辅相成：</p>
</div>
<div class="paragraph">
<p>精心设计和经过充分测试的代码是所有敏捷团队的目标之一。在 InnerSource 设置中，团队成员以及团队外部贡献者的上岗都会变短。</p>
</div>
<div class="paragraph">
<p>熟悉协作、避免分配任务的团队也能以灵活的方式处理外部贡献。此外，他们的思维方式和沟通方式也能很好地激励那些他们无法直接影响其优先级的贡献者。利用内在动力而不是指挥工作，意味着项目主办团队拥有与贡献者成功合作的工具。</p>
</div>
<div class="paragraph">
<p>结对解决问题的团队已经习惯于尽早分享进展。从结对文化转向 InnerSource 有两个挑战：项目主办团队需要为支持贡献者安排时间，并将其纳入计划工作。此外，当跨越团队边界时，往往很难找到刚好匹配的时间段——在这种情况下，应辅之以异步协作。在 InnerSource 环境中，为了避免频繁的干扰，主办团队成员往往需要有意识地更严格地规划自己的一天。通常，最简单的方法是在一天中留出某些时间或每周留出一天用于指导贡献。在团队层面明确规定这一点，既能减轻工程师的压力，让他们努力实现自己的团队目标，又能帮助贡献者。结对的另一个挑战是，它允许结对人员一起快速行动，但这往往以为团队其他成员写下重要信息为代价。在 InnerSource 环境中，确实需要进行培训，以牢记将所有相关决策带回共享的沟通渠道，供团队和贡献者双方使用。从产品的角度来看，这确实会提高开发过程的透明度。这也意味着，原本可能只在工程层面做出的决策，现在对所有相关人员都是可见的。</p>
</div>
<div class="paragraph">
<p>还记得上次你坚持要对产品进行完善的测试，最好是自动化测试，这样就可以在无需人工干预的情况下频繁部署产品了吗？现在，这一目标对 InnerSource 也有帮助：如果贡献者可以在本地检查他们的修改是否安全，那么贡献就会容易得多。测试还能确保托管团队在测试失败的情况下记得保留所贡献的功能。</p>
</div>
<div class="paragraph">
<p>还记得上次你坚持让团队花时间遵循“让代码变得比你发看到它时更好”的目标吗？这种心态有助于 InnerSource 模型：它能确保代码的质量和凝聚力，即使有来自不同来源的多种贡献，也能保持较高水平。</p>
</div>
</div>
<div class="sect2">
<h3 id="_common_misunderstandings_when_coming_from_agile_teams">来自敏捷团队的常见误解</h3>
<div class="paragraph">
<p>InnerSource 和敏捷使用一些相同的工具，但目的不同。</p>
</div>
<div class="sect3">
<h4 id="_impact_of_overlapping_language">语言重叠的影响</h4>
<div class="paragraph">
<p>问题跟踪：在敏捷团队中，用户故事是与客户的对话。通常它们会作为便签贴在白板上。但它们通常也存储在问题跟踪器中。因此，问题跟踪器主要被视为规划工具，本质上是白板上便签的替代品。在 InnerSource 中，问题跟踪器用于与客户进行对话，还用于在一个公共 InnerSource 组件上工作的受信任提交者和贡献者团队的成员之间进行通信。 InnerSource 中的问题比一般组织中的问题更加冗长和啰嗦。他们还跟踪变更的实施历史和详细设计决策。</p>
</div>
<div class="paragraph">
<p>代码评审： 在传统组织中，代码审查通常是出于审计目的。</p>
</div>
<div class="paragraph">
<p>当开发完成时，代码评审就完成了。在 InnerSource，代码变更在开发过程的早期就会共享，有时甚至只完成了一个粗略的草图。这样做的目的是寻求早期反馈和指导。这对那些日程安排繁多、没有时间结对编程的团队特别有帮助。团队通常都有一个愿望，那就是没有人是孤独前行的，但在现实中，这往往只是一个从未实现的愿望，特别是当贡献跨越团队界限时。</p>
</div>
<div class="paragraph">
<p>InnerSource 中使用的工具可以将这一要求正式化，即任何变更都必须有不止一个人参与。</p>
</div>
<div class="paragraph">
<p>注重书面沟通：InnerSource 的目标是让项目足够透明，以便非团队成员的开发人员能够理解项目决策并遵循软件创建过程。因此，所有沟通都需要放在每个对对话感兴趣的人都可以跟进的地方：书面的、公开的、可搜索的和可链接的。目标不是减少对他人的干扰——目标是使所有项目对话透明。</p>
</div>
<div class="paragraph">
<p>因此，应避免直接消息和邮件。为了使每个人都能更轻松地进行后续对话，应在一个单独的沟通渠道中跟踪与一个 InnerSource 项目相关的消息：目标并非触达 InnerSource 项目团队中的每个人，而是为参与该项目的每个人找到一个共同的共享房间，他们可以在那里重点讨论该 InnerSource 项目。</p>
</div>
<div class="paragraph">
<p>注重书面交流并不意味着不允许口头交流，仍然需要时间一起喝杯咖啡。此外，一起解决问题、与他人结对或亲自参加黑客马拉松对于快速找到解决方案也很有价值。团队需要确保所有项目相关决策都保存在每个人都可以访问的渠道中。这也可能意味着推迟重要的项目决策，直到每个人都休假回来，或者如果在另一个国家工作的人现在正在度假，则需要再等待一两天。这不仅与编码决策相关，还与总体项目任务、路线图和方向相关。如果没有这些信息，贡献者将很难理解哪些贡献将有很好的机会被接受。</p>
</div>
</div>
<div class="sect3">
<h4 id="_impact_of_trust">信任的影响</h4>
<div class="paragraph">
<p>InnerSource 项目中的所有讨论对公司中的每个人都是可见的。指责、嘲笑嘲笑他人的错误，在背后谈论他们做错的事情，肯定会扼杀这种信任，并导致 InnerSource 项目的失败。这对于任何处于领导或榜样地位的人来说尤其重要。</p>
</div>
</div>
</div>
<!--- This file autogenerated from https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/main/scripts -->
Loading