注：本文翻译自《Development For Winners》一书的计划章节的部分内容，主要包括敏捷开发相关的内容以及一些术语。
原书链接：https://grofit.gitbooks.io/development-for-winners/content/planning/readme.html
这一章将涉及到这样一个过程，从拥有一个点子，到你能够确定知晓需要为其进行哪些工作，即将这个好点子转化成对于你（或者其他人）来说可以去做的切实可行的任务。这里将讨论一些工具和方法可以帮助你加快计划阶段的速度，在大部分的内容中，我们将看一些有关于敏捷开发的东西，它们很受欢迎并且都带有在线文档。
拥有一个点子
你已经拥有了一个关于独立游戏或者应用的非常棒的能让你成为百万富翁的点子，你已经想的非常完善了，并且你已经决定要从“想”的阶段过渡到“做”的阶段了。
现在，不要急着立马冲进去实现那些在你脑海中如洪流般的想法，而是需要退一步，思考一下更高层的东西：你想要做的是什么？以及你将要如何实现它们？
它是什么？
作为团队的成员或者发行人，在你去任何地方之前，先为你的游戏或者应用写下一个简短的概要或者说明，试图去描述主要的机制，例如如果它是一个平台游戏，那么哪里可以让它与众不同。如果是一个RPG游戏，就详述一下高层级的故事框架或者其他一些东西。你可以向任何其他人展示这些东西，以便于他们能够理解你的这些点子都是从哪来的。
很多人在刚开始都是自己一个人去开始一个想法的实现，这样很好。但是当前的现实是想要独立一人开发一个完整的游戏是相当困难的。因此，很可能的是在某些节点上你将需要把其他人拉入项目来帮助你。如果没有一些关于“你正在努力实现的是什么？”的高层级的介绍，对于新加入的人来说，想要理解并认可你的想法可能就会很困难。因此，当你写概要的时候应该仔细的思考你正在做的是什么。
这些方法也能够在你的想法如脱缰的野马般不受控制时，帮助你进行锚定。它不需要很长，仅仅只需要几个段落描述清楚你的游戏即可。
什么是敏捷开发？
敏捷开发只是又一个用于长线项目开发的最新的方法论而已，就像瀑布式开发（译者：原文为waterfall）,受控环境下的项目管理（译者：原文为prince2）以及其他的一些方法论一样。（译者：此处提到的几个概念都是软件开发中所使用的方法论）
敏捷开发与其他的方法不同的地方在于它并不复杂，而且很适合技术型的项目。它不仅包含如何管理项目，也包含了如何去实验和提高，以及有规则的去验证和量化你的项目。
敏捷开发还有很多指导性的原则，例如：如何管理敏捷会议或站立会议的面板，在给定时间内有多少工作需要完成，以及个人如何在团队中工作等等。实际你完全可以自己决定该怎样工作,只要你是务实的，能够确定自己的计划并能够经常测试自己的东西，那么团队中的每个人都将会很愉快。
高水平的敏捷开发意味着更多的交流，团队决策，合理的需求，更频繁的交付以及软件测试，然后获得反馈来进一步提升所做的事情。所有的这些听起来应该都是平日里的常事，接着我们将会接触到更多有关于敏捷开发的东西。
如果你是一个独立开发者或者你的团队人数不超过3人，那么可能很多事情对于你来说都是过分之举，但是敏捷开发环境中（稍后会提到）的一些好的实践依然适用于独立开发者和小团队。
步骤
有关于敏捷开发的每个阶段都有完整的声明以及大量的在线信息，并且还有大量的文本详细的描述了在每个阶段你应该花费多长时间，以及应该让谁参与等等。但是，这里在更高的层级上把这些都当作步骤。
无需担心是否你在看完这些内容和相关的术语后会感到厌烦，我知道很多读者想要看的是与技术相关的东西而不是与项目管理有关的废话。但是知道这些东西真的非常有用，不过，你仍然可以跳过这些部分直接去读有关于工具和需求的章节，看一下这些被探讨的步骤是如何应用于实践的。
开始
开始阶段就是你想出下一个冲刺(译者：可以把冲刺想像成制定一个短期的目标，并在指定的时间内将其完成)中想要实现的故事（译者：原文此处为stories，更多的信息请参考术语部分）和任务是什么。在这个阶段，你将会经常的增加一些故事到待办事项中，也会想到哪一个故事会在下一个冲刺中进行。
一些团队将会有分析师（通常是公司的业务分析师）于此时参与创建故事，依赖于你的团队规模，你可能必须参与进去并提供帮助，通常你需要提前知道这些事情：
这一个冲刺需要多长时间？
能做多快？
有多少个人参与这个冲刺？
一旦你知道了这些问题的答案，你就可以聚集起每一个人，计划出这个冲刺的目标是什么，判断出都有哪些故事与这个冲刺相关，接着就能够知道完成这个冲刺目标都需要做多少工作。
即使你没有完成一个冲刺中的所有的工作，也不代表这就是世界末日，有时你能够完成，有时你可能比预想的多做或者少做。最主要的是你要将每个冲刺阶段完成的工作展示给团队中的其他人看，以便于其他人能够了解每一件事情都持续了多长时间，这一点在回顾时会更为重要。
构建/开发
这个阶段每天都会有站立会议，每个人都去设计代码以便于完成故事。这个阶段解释起来最简单，尽管这个阶段有很多的开发工作，并且真实的项目中也会有一些其他的事情，例如自动化的构建和部署，以及测试和验证已完成的工作是否符合标准等等。
部署/回顾
由于敏捷开发的额外推崇，这个阶段被认为是事情对多的阶段。但是，如果你忽略这些说法并且认真观察，就会发现这个阶段（或者是多个更小的阶段）发生的都是类似的事情：根据环境需求部署你所做的工作，然后回顾这个冲刺阶段的进展。
类似于自动化的部署和技术问题的跟踪可以在这个阶段花费一些时间去做，因为它们将会加快你的部署速度，也能够让你更容易的移植到其他环境中。
根据你的情况，回顾可以是正式的也可以是非正式的。在现实情况中通常人们只对事情的发展方式提出一些担忧，并只想尽快的解决这些担忧。但是，对于回顾的良好建议是：你可以找出一些可以在下个冲刺中尝试或者提高的点。例如：你可能发现在这次冲刺中你的需求没有被完全的实现，因此你可以在未来的冲刺中对这部分内容进行提升。或者在这个冲刺中有很多的技术债务（译者：原文为technical debt）并且它们引发了问题，那么在下一个冲刺中就可以减少50%的待办故事，先去解决这些技术债务问题等等。
一些与敏捷开发相关的术语
在敏捷开发的这一章或者未来的一些章节中，会有很多的术语将会被提及，因此，在这里列出了一个术语表，用来解释每个术语的意思。
故事（Story）
一个故事大体上是一个高层的需求，描述了你需要去实现的东西，一个故事应该包含被认可的标准（在稍后会有更加详细的描述）。故事可以被看作是高级的特性，例如“创建一个登陆系统”，这实际上可以被分解成一些更小的任务，即包含这个故事中的所有的开发任务，例如：
创建登陆界面
创建用户认证API
存储用户的登录令牌
一个故事中通常也会有一个预估，下面就会提到这个术语。
预估（Estimate）
这个术语是可以根据字面意思来理解（译者：自解释的），在敏捷开发的世界中，预估通常是一个抽象的数字，通常使用精力点或者故事点来计算预估值，例如：
1 - 不需要很多精力
2 - 平均精力
4 - 很多的精力
8 - 这太过分了，取消这个故事吧
通常你需要针对每一个故事需要花费多少精力做出所有的预估，我们上方提到的“创建登陆系统”的故事可能需要4（很多的精力）的精力去实现。
如果你不能确定一个故事需要花费多少精力，一个不错的方法是，先从一个最早的你认为最简单的故事开始，把它当作一个基准，作为a1或者a2，接着再算出下一个故事是需要一倍的精力还是一半的精力。
如果你在故事这一层级上的估算遇到障碍，可以尝试先从任务（译者：任务比故事低一个层级，可以认为一个故事中包含很多个任务）开始估算。对于技术人员来讲通常会比较容易。很多的敏捷开发的专家也都会在此阶段叹气。但是即使只能对你所做的事做个粗略的预估，也好过即兴发挥，然后抱乐观的希望。
当我们在任务的层级上进行评估时，创建一个登陆界面可能需要2（平均的精力），但是创建用户认证API可能需要4（很多的精力），存储用户的登录令牌需要1（不需要很多精力），因此，这个故事点总计需要7点的精力。
对于一个故事应该是多大没有硬性的要求，如果你倾向于制作粒度化的故事，那么就把它们分成一些很小的块。如果你的团队熟悉这个领域并且之前已经用过这项技术，那么你就能制作一些有类似特性的更大的故事。
还有一点儿值得注意的是，在实现一个故事时，人们经常会用出牌（play（译者：根据后面作者比喻成打牌，因此将此处的play译为出牌））这个术语，好像一个故事或者任务是一张你将要从手中打出的牌。
冲刺（Sprint）
一个冲刺是指在一定的时间内去实现的以故事为基础的一项功能目标。通常时间为2个周，你需要提前确定所做的东西到最后想要实现成什么样子。
待办事项（Backlog）
通常指的是一个项目中的所有的故事，如果你想去做一个类似超级玛丽的游戏，你可能有100个故事需要去做，可能需要10个冲刺，因此待办事项作为故事的主列表是有必要的，在新的冲刺中经常会有更多的故事不停的被添加进去，也有一些故事没有被完成，技术债务等也会被添加进去。
站会/敏捷会议（Standup/Scrum）
实际上在敏捷开发中，敏捷会议是被额外推崇的，但是很多人会混用敏捷会议和站会这两个术语。
敏捷会议在每个早上进行，处在一个冲刺中的团队成员聚集到一起快速的说一下自己正在做的事以及所遇到的障碍。
在你的观念中不应该花费太长时间在这上面，它只是需要正式一下而已，对于一个超过4人的团队，快速的站到一起讨论可能是个不错的方式，但是没有什么硬性的规定。
在这里涉及到的最主要的事情就是障碍，你可能需要团队中的其他人的帮助。
许多人的关注点是昨天都做了哪些工作，但是当你观察一下故事的状态以及之前的站会就能看出，在大部分的情况下这些并不重要。因此，如果你能够避免谈论这些，而去关注任何遇到的障碍和现在正在考虑的事情，会议的速度会大大的提升。
障碍（Blockers）
这是一些阻止你继续实现故事或者任务的东西，它们可能会让你停下，直到其他的一些故事或者任务完成后，你才能继续。或者一个第三方库存在一个bug，或者你只是无法从技术上解决这个问题。
回顾（Retrospective）
在一个冲刺结束后通常会进行一次回顾，讨论一下哪些事情进展顺利，哪些事情需要在下一个冲刺中提升。回顾的时间可长可短，对于一个大的团队来说可以通过一些小游戏来帮助团队成员谈论项目，对于只有几个人的团队只需要简单的找到可以提升的点，并尝试在下一个冲刺中实现它们。
时间盒（Time boxing）
这个术语通常跟障碍或者一些技术调查一起使用，大体上你将说明需要花费多长的时间来调查一些东西，接着讨论你的发现，并且计划下一步该如何进行。
因此，如果我在任务中遇到一个第三方认证框架无法返回正确数据的障碍，我就可以安排3个小时的时间（译者：这个3小时的时间就是一个时间盒）去尝试使用不同的框架，进行返回验证，看一下是否其他的框架能够以一种更好的方式解决这个问题。
从较高的层级上来看，对于为技术债务寻找一个更好的解决方案，使用时间盒是一个非常有用的策略，针对一个问题你可以设置几个小时的时间来尝试不同的解决方案，然后确定哪一个是最好的，而不是随意的挑选一个，然后将你的所有时间都花费在上面。你必须要务实，至少让其他人知道你的调查预计需要消耗多长时间。
技术债务（Technical Debt）
在你实现故事或者任务时，毫无疑问的你将不得不走一些捷径，以及做一些你不喜欢做的事，例如在一些地方的配置上使用硬编码，因为你没有时间去完成一个配置加载器，或者你可能在发布版本中留下一个恼人的bug，只因为在这个冲刺结束前你没有足够的时间去解决它。
这就是技术债务出现的地方，你不仅仅需要记住（或者忘记）哪些技术需要提升，也要在待办事项中使用特殊的标记创建任务，或者约定一个标识：这不是一个基于故事的特性，而是一个技术提升，将需要在以后的某个时间完成。
技术债务是很重要的概念，但是很多团队并不跟踪它们。它会给人一种任务完成的假象，实际上你可能隐藏了很多的问题。并不是说你总是需要去解决所有的技术债务，而是，一个项目中未解决的技术债务越多，在某些情况下，增加新特性就会越难或者越慢，而你将会被钉在难以修改的代码之上。
速度（Velocity）
速度是指一个团队在一个冲刺中可以真实完成的故事的数量。它更像是一种汇报机制，但是对于你了解估算未来的冲刺需要消耗的时间非常重要。
因为当你做一个冲刺时，你无法知道需要完成多少工作（再次假设这是一个2个周的冲刺）。让我们假设你能够在2个周的时间内完成10个故事点，但是冲刺结束时你只完成了8个故事点。这就意味着在下一个冲刺中，你就能大体知道自己能够完成多少个故事点。
速度是一个衡量团队生产力的很好的标识，也能够测定出你的项目可能需要多少个冲刺，它也能够帮助你判读出在不影响最终交付的情况下，你是否能够在一个冲刺中去设法解决一些技术债务。
