fix some Chinese translation spell mistake

make some statements smoother
davebs · May 22, 2019 · 70fb308 · 70fb308
1 parent b8372af
commit 70fb308
Show file tree

Hide file tree

Showing 4 changed files with 10 additions and 10 deletions.
diff --git a/chinese/README.md b/chinese/README.md
@@ -1,26 +1,26 @@
 # 精简版敏捷：敏捷而不会有丝毫倦怠
 
-「敏捷软件开发」是个很好的主意，但是被出版商和咨询机构过度复杂化了。精简版敏捷（Agile Lite）旨在简化这种情况。你不需要一本书或者开一个研讨会才能解释清除精简版敏捷。你只需要一个包含几个段落的文档文件，而这就是那个文档文件。
+「敏捷软件开发」是个很好的主意，但是被出版商和咨询机构过度复杂化了。精简版敏捷（Agile Lite）旨在简化这种情况。你不需要一本书或者开一个研讨会才能解释清楚精简版敏捷。你只需要一个包含几个段落的文档文件，而这就是那个文档文件。
 
-精简版敏捷是相当简单的。它能够被应用到任何工作项目上，只要这个工作能够被拆成更小的任务组件，我们将这些任务组件称为事项（Issues）。像其它敏捷方法论，精简版敏捷也使用较短的开发周期，我们称之为冲刺（Sprints）。有点独特的是，精简版敏捷明确承认软件开发行业普遍存在职业倦怠，并且试图通过 3 周开发／1 周不开发的周期来缓解这种情况。
+精简版敏捷是相当简单的。它能够被应用到任何工作项目上，只要这个工作能够被拆成更小的任务组件，我们将这些任务组件称为事项（Issues）。像其它敏捷方法论一样，精简版敏捷也使用较短的开发周期，我们称之为冲刺（Sprints）。有点独特的是，精简版敏捷明确承认软件开发行业普遍存在职业倦怠，并且试图通过 3 周开发／1 周不开发的周期来缓解这种情况。
 
 基本步骤如下：
 
-* 每个周期的第一周用于项目负责人、开发者和其它业务方定义即将到来的`冲刺`。 尽管分配了一周，但是如果顺利的话，冲刺计划会议不应该超过 2 小时，可能只需要 45 分钟左右。 这是故意轻松的一周，许多人可能会抽出时间去画画、冲浪或者其他什么事情。
+* 每个周期的第一周用于项目负责人、开发者和其它业务方定义即将到来的`冲刺`。尽管分配了一周，但是如果顺利的话，冲刺计划会议不应该超过 2 小时，可能只需要 45 分钟左右。这是故意轻松的一周，许多人可能会抽出时间去画画、冲浪或者其他什么事情。
 
-* `冲刺`在这个周期里面的后三周里面进行。在这期间，工程师完成在冲刺计划会议上分配给自己的事项。因为团队可能是完全远程的，成员分布在各个时区，「实时」会议可能不会经常进行，大多数沟通可能通过`事项跟踪系统`（它用起来比电子邮件系统更快）来进行。一个类似于 Trello 的共享看板就是一个很好的事项跟踪系统，而电子表格就不是。不鼓励每日站会；通过查看事项跟踪系统的更新，就能获得项目的基本进度。
+* `冲刺`在周期的后三周里面进行。在这期间，工程师完成在冲刺计划会议上分配给自己的事项。因为团队可能是完全远程的，成员分布在各个时区，「实时」会议可能不会经常进行，大多数沟通可能通过`事项跟踪系统`（它用起来比电子邮件系统更快）来进行。一个类似于 Trello 的共享看板就是一个很好的事项跟踪系统，而电子表格就不是。不鼓励每日站会；通过查看事项跟踪系统的更新，就能获得项目的基本进度。
 
 * 一旦`冲刺`开始，就不能往里面新增事项，但是可以移除事项。这减少了上下文切换，是一件好事情。
 
 * 在冲刺期间未完成的事项，将在下一个冲刺计划会议中进行审核，并决定是将它加入到下一个冲刺，还是将其重新放回 Backlog，还是将其重新分配给其他开发者。
 
 * 一个事项要么在 `backlog` 里面，要么在`当前冲刺`里面。
 
-* 如上所述，我们鼓励开发者在计划周的期间里放松一下，让他们的大脑从之前的冲刺中恢复过来。 这里没有死亡竞赛。 开发者在周末不工作。 这一切都有助于避免倦怠，而避免倦怠对每个人都有好处。
+* 如上所述，我们鼓励开发者在计划周的期间里放松一下，让他们的大脑从之前的冲刺中恢复过来。这里没有死亡竞赛。开发者在周末不工作。这一切都有助于避免倦怠，而避免倦怠对每个人都有好处。
 
 虽然大部分工作可以在给定冲刺里面被安排好，但有时确实会发生意外。这些意外事项称为`支持事项`。
 
-我们建议在冲刺计划期间为团队中的某些成员分配属于不可预期的支持事项的时间。例如，“戴维在下一个冲刺期间有 12 个小时可以被用于支持事项（具体内容将在后面定义）”。轮流在冲刺期间承担支持事项同时对整个团队是有益的。
+我们建议在冲刺计划期间为团队中的某些成员分配属于不可预期的支持事项的时间。例如，「戴维在下一个冲刺期间有 12 个小时可以被用于支持事项（具体内容将在后面定义）。」轮流在冲刺期间承担支持事项同时对整个团队是有益的。
 
 为了提高估计的准确性，在每个冲刺计划会议中，都会检查在上一个冲刺中实际完成的支持工作量，并确定在下一个冲刺中是否需要*增加*还是*减少*用于支持工作的时间。
 

diff --git a/chinese/agile_lite_for_developers.md b/chinese/agile_lite_for_developers.md
@@ -16,7 +16,7 @@
 
 * 一旦冲刺启动，事项不可以再往里面添加，但可以从里面移出。这能减少上下文切换，是一件好事。
 
-* 事项是所有工作的基本单位，它需要工程师花 4 ~8 个小时的精力去完成。一个事项要么在当前冲刺中，要么在 backlog 里面。
+* 事项是所有工作的基本单位，它需要工程师花 4~8 个小时的精力去完成。一个事项要么在当前冲刺中，要么在 backlog 里面。
 
 * 任何在当前冲刺结束时还未完成的事项，需要在下 1 周的冲刺计划会上进行检查回顾。
 

diff --git a/chinese/agile_lite_for_managers.md b/chinese/agile_lite_for_managers.md
@@ -2,7 +2,7 @@
 
 在你的公司里面，和软件开发者合作是一个挑战吗？你是否看到过一直延期的项目？你是否曾与那些一开始很好然后慢慢热情降低，最后消失的开发人员合作过？你可能只是在这个项目中和一个经历倦怠的天才开发者打交道。
 
-职业倦怠在软件行业中非常普遍，这是许多软件项目失败的关键原因。对于职业倦怠可能最好的描述是一种和特定项目或组织有关的创伤后应激障碍的症状。例如，只要一提到某个项目，你就会大脑宕机，变得非常焦虑。这是倦怠。处于这种状态的开发者可能无法继续从事该项目，并且可能会在接下来的几个项目中降低生产力。职业倦怠会对职业生涯造成伤害。
+职业倦怠在软件行业中非常普遍，这是许多软件项目失败的关键原因。对于职业倦怠可能最好的描述是，它是一种和特定项目或组织有关的创伤后应激障碍的症状。例如，只要一提到某个项目，你就会大脑宕机，变得非常焦虑。这是倦怠。处于这种状态的开发者可能无法继续从事该项目，并且可能会在接下来的几个项目中降低生产力。职业倦怠会对职业生涯造成伤害。
 
 有很多种原因会导致职业倦怠，但是最基本地来说就是每天工作时间太长、工作压力太大，而且是长期这样。
 

diff --git a/chinese/faq.md b/chinese/faq.md
@@ -20,7 +20,7 @@
 
 > 人们在冲刺中对事项进行*承诺*还是他们*预测*事项在这个冲刺中将会由他完成？
 
-他们预测。如果你的估计太短而实际没完成，那不是道德上的失败。这是整个过程的一部分，每个人都在同一个团队中。
+他们只是预测。如果你估计得太短而实际没完成，那不是道德上的失败。这是整个过程的一部分，每个人都在同一个团队里面。
 
 > 我们能将冲刺称之为迭代吗？
 
@@ -84,4 +84,4 @@
 
 > 你正在做一个错误的敏捷。
 
-不幸的是，敏捷存在的问题就是不可能被做正确
+不幸的是，敏捷存在的问题就是不可能被正确地实践。