README 部分
「敏捷软件开发」是个很好的主意，但是被出版商和咨询机构过度复杂化了。「轻量敏捷」旨在简化这个情况。解释轻量敏捷的时候，你不需要一本书或者开一个研讨会。你只需要一个包含几个段落的文档，而这就是那个文档。
轻量敏捷是相当简单的。它能够被应用到任何工作上面，只要这个工作能够被拆成更小的任务组件，我们将这些任务组件称为「事项（Issues）」。像其它敏捷方法论，轻量敏捷也使用较短的开发周期，我们称之为「冲刺（Sprints）」。有点独特的是，轻量敏捷明确承认软件开发行业普遍存在职业倦怠，并试图通过「3 周开发 / 1 周不开发」的周期来缓解这种情况。
基本步骤如下：
-
每个周期的第一周用于项目负责人和业务方定义即将到来的冲刺。 尽管分配了一周，但是如果一切顺利，「冲刺计划会议」不应该超过 2 小时，可能只需要 45 分钟左右。 这是故意轻松的一周，许多人可能会抽出时间去画画、冲浪或者其他什么事情。
-
冲刺在接下来的三周里面进行。在这期间，工程师完成在冲刺计划会议上分配给自己的事项。因为团队可能是全远程的，成员分布在各个时区，「实时」会议可能不会经常进行，大多数沟通可能通过事项跟踪系统（比电子邮件系统更快）来进行。一个类似与 Trello 的看板就是一个很好的事项跟踪系统，而电子表格就不是。不鼓励每日站会；通过查看事项跟踪系统的更新，就能获得项目的基本进度。
-
一旦冲刺开始，就不能往里面加事项，但是可以移除事项。这减少了上下文切换，这是一件好事。
-
在冲刺期间未完成的事项，将在下一个冲刺计划会议中进行审核，并决定是将它转发到下一个冲刺，还是将其重新放回 Backlog，还是将其重新分配给其他开发人员。
-
一个事项要么在 backlog 里面，要么在当前冲刺里面
-
如上所述，我们鼓励开发人员休假，让他们的大脑从之前的冲刺中恢复过来。 没有死亡竞赛。 开发人员在周末不工作。 这一切都有助于避免倦怠，而避免倦怠对每个人都有好处。
这就是所有内容。 这个系统并没有真正规定工程实践，我认为这没问题。工程实践可以在每个项目级别进行定义。
因为有时会发生意料之外的必须要处理的事情，这些日常支持工作应该轮流安排人去完成，而事项可以等到以后去完成。
轻量敏捷是一种更好、更可持续的软件开发方式。 它为软件开发人员提供支持，同时为项目业务方提供始终如一的可靠的生产力。
开发人员的轻量敏捷
如果你已经在软件行业里面工作了几年，那你很可能已经经历过职业倦怠。职业倦怠有很多中原因，最简单地说起来就是长期工作时间太长、工作压力太大导致的。
这起源于某个项目。这个项目有详细的说明文档和截止日期。当说明文档改变时，截止日期没有变。最终接近截止日期时，说明文档和它最初的模样变得不一样了。这当然这被认为是你的过错，你也总是被要求呆到很晚或者对这个「变形目标」进行承诺。最终无论你工作有多努力，你周末也得加班，你的经理也一直不高兴，项目永远落后于进度表。
想休假或者度假会让你看起来是一个懒鬼。这让你看起来是团队的支持者。也许你在一个开放的办公环境工作：每个人都知道你什么时候到和什么时候离开，每个人都对潜规则心知肚明，不能成为那个工作最不努力的人。所以大家都很擅长装作很忙，无论何时别人问你在干什么，你都是回答：“忙啊，我真的很忙！”
但是最终会有事情发生。也许你会换工作，但这很可能是软件行业的另一家公司。也许你会坚持下去，知道公司让你离开，因为你「和公司文化不匹配」。也许你会离开这个行业，找了个汽车销售的工作，因为编程太有挫败感了。正如某句话所说，扼杀业余爱好最好的办法，就是以此谋生。
我正提出一个解决方案。它是某种精心设计的，避免倦怠的敏捷形式，我称之为轻量敏捷：
-
最基本的规则是：每个周期包含 3 周的冲刺和一周的冲刺后的休息。3 周开发 / 1 周不开发
-
冲刺会包含许多事项，工程师解决事项、记录相关问题并且在事项跟踪系统上更新
-
一旦冲刺启动，事项不可以再往里面添加，但可以从里面移出。这能减少上下文切换，是件好事
-
事项是所有工作的基本单位，它需要工程师花 4 ~ 8 个小时。一个事项要么在当前冲刺中，要么在 backlog 里面
-
任何在当前冲刺结束时还未完成的事项，需要在下 1 周的冲刺计划会上进行回顾
-
没有任何加班费。没有死亡竞赛。工程师定时工作，并且有充足的时间给大脑充电。最小化的管理开销。
这就是所有东西。它能够按你的目的修改。但是如果要说「轻量式敏捷」的一大不同的话，那就是我们明确地说，「敏捷团队和许多其它开发方法一样，正在经历职业倦怠，也许我们需要建立明确的规则来防止工程团队的引擎过热。」
让我们停止过度加热我们的引擎。总会有许多工作要做，但这是一个深不见底的坑。短暂的人生如果全用来在压力下工作，最终我们就会倦怠。