敏捷规划，让你做一个有计划的开发人
摘要：新的一年即将开始，你在2020计划完成的事已实现了多少？我们知道，很多人会在新年伊始满怀期待的做计划，并努力做好时间管理，但是当计划赶不上变化的时候，往往会措手不及，一再耽搁。因此我们需要明白“响应变化高于遵循计划”的原则。那么如何维持这两者之间的平衡，高效的完成一件事，这个问题也正是这篇文章所要和大家分享的，如何在敏捷开发中做计划，即敏捷规划。
一个人不能没有生活，而生活的内容，也不能使它没有意义。做一件事。说一句话，无论事情的大小，说话的多少，你都得自己先有了计划，先问问自己做这件事，说这句话，有没有意义?你能这样做，就是奋斗基础的开始奠定。——戴尔·卡耐基
2020年马上就要过去了，很多公司和团队以及个人都陆续着手这整年工作的归纳和总结，与此同时也开始对新的一年的展望。从小编上大学开始（那好像是一个很久远的时候……），大家会在QQ空间或者QQ签名上写一些很正能量的话以肯定自己一年的努力和鼓励自己在新的一年能百尺竿头更进一步。当然很多有心人不仅是心怀美好期盼，而且还做了新一年的计划，比如，使用近些年来比较流行的bullet journal——子 弹笔记。子 弹笔记能它能让你在短时间内找到最重要的事情，高效的做好时间管理，告别盲目的做事情。在记录的时候，记得都是关键词或短句子，并且配合着一定意义的符号有条理的排列内容，给人一种简约和清爽的感觉。
-------图片来源于网络
子 弹笔记之所以被全球范围所推广和认可正是以为这样简约、高效的做计划的方式，其实这也正是遵循了现实的生活状态，即我们需要高效的同时，正每时每刻不再面临着变化，而详尽复杂的计划往往只是费力不讨好。这在软件行业中也是一样的。
原来的瀑布式开发的方式已经无法适应当今快速的变化，详尽周密的计划必定无法指引软件走出VUCA时代所带来的“黑暗”，而敏捷开发的方式应时代所需势在必行，因为在敏捷宣言中就提出了“响应变化 高于 遵循计划”的口号。可能有些读者会有疑问说“难道敏捷就不做计划了吗？”，其实不是这样的。敏捷一样需要做计划。那么有些读者可能又会问“不是说响应变化高于遵循计划吗？怎么还做计划呢？”其实敏捷宣言不是说不做计划，而是说相比做计划更有价值的是响应变化，一切以变化为依据。那么有读者可能又会问“既然当今世界无时不刻不再变化，你如果响应了变化还怎么做计划呢？”很高兴有读者会有这样的疑问和思考，而这个问题也正是这篇文章所要和大家分享的，如何在敏捷开发中做计划，即敏捷规划。
什么是敏捷规划
敏捷规划是一种逐渐完善过程的规划方法，是对价值的探求过程。规划为一个概括性的项目开发问题“我们要构建什么？”找到最佳的答案，这一答案综合了功能、资源和进度三个方面。规划应该足够可靠，可以用来作对该产品和项目进行决策的基础。敏捷规划更关注规划过程而不只是建立一个计划。它鼓励修改、产生易于修改的计划，并且延续到整个项目过程。
敏捷规划有效的原因
- 经常进行重新规划
- 在不同层次上制定计划
- 基于功能而不是基于任务制定计划
- 小故事保持工作流畅
- 每次迭代都要消除处理中的工作
- 在小组层次跟踪
- 承认不确定性并为之做计划
敏捷规划和传统规划的区别
敏捷规划追求真实需求，重复初始计划
敏捷团队开始时对项目的愿景有一个初步的讨论，之后用原型进行迭代。干系人可以在原型的基础上对项目进行反馈和调整。而在瀑布计划中，范围和解决方案还没有确定就需要干系人对项目进行详细的说明和反馈。敏捷通过原型来更好的理解相关领域，并以原型为基础进行进一步的计划和细化，这也体现了渐进明细的概念。
敏捷规划贯穿于整个项目中，不仅仅是前期的工作
传统规划中强调前期计划的重要性，主要集中在项目范围规划、时间规划、成本规划、质量规划、人力资源规划、沟通规划、风险规划、采购规划、干系人规划以及变更管理、配置管理和过程改进等相关计划上。这些过程都在项目开始之前就需要执行。敏捷恰恰相反，敏捷认为知识型项目的风险等级和不确定性使得前期计划出现了许多问题，所以敏捷方法提倡在整个项目生命周期中都进行规划，会有不同层次和详细程度的计划。但是， 敏捷认为前期计划是很有必要的，只是不宜过度，需要找到一个平衡点，既要做好足够的前期计划以减少大量重复和返工的风险，也能避免过度计划导致ROI下降以及多变的项目计划。
敏捷规划是移动打靶，需要及时调整中期计划
当目标是静止的时候，可以做很多计划，从而向着那个静止目标努力前进，当目标是移动的时候，就更加需要作出大量中期调整以保证目标达成，类似移动打靶。为了达成目标，敏捷方法使用了复杂的探测和适应系统去获取反馈并作出调整。
敏捷规划的原则
- 假设事先无法制定完美的计划
- 事先规划有帮助，但不宜过度
- 最后责任时刻再敲定计划
- 关注调整与重新规划胜于与遵循计划
- 正确管理WIP
- 提倡更小、更频繁的发布
- 快速学习规划并在必要时候调整方向
敏捷规划的方法
规划各层级计划，明确产品开发的方向
在敏捷方法中，早期的计划是必要的，但有可能是不太完美的。不确定性导致了重复计划的必要性。为了体现适应性计划的特点，分别为：敏捷愿景、产品计划、版本计划、迭代计划、每日站会计划。计划的层次体现了渐进明细的特点，渐进明细的最终目的是为了交付与原始设计对象一致的产品。五层计划体现了在敏捷项目中一些细节不断涌现，需要根据反馈重新排序优先级，从而调整整个项目。这一点体现了敏捷宣言中的最后一条“响应变化胜过遵循计划”。五层计划如下图所示。
定义愿景
规划洋葱图的顶端是愿景层。产品愿景要清楚描述从哪些方面为用户或者客户之类的利益干系人提供价值。这一层是定义产品要解决的首要问题和产品的目标人群。考虑这些问题有助于了解产品为用户带来的真正价值，和如何让产品与其他试图解决相同问题的产品区别开来。
确定产品概要列表和路线图
开始时必须产生一些最基本的需求来填充产品列表，在确立列表之后，建立一个产品路线图。路线图要有时间轴、版本号和对应的特性功能信息。路线图可以表示产品随着时间的推移如何以增量方式构建和交付，以及驱动每一个版本的重要因素。
制定版本计划
根据产品路线图的时间路标从产品列表中选取适当的特性进入对应的版本计划中。版本规划是主要针对增量交付取得范围、日期和资源之间的平衡。每个企业和公司都需要有一个合适的节奏，有规律的向客户交付产品特性。迭代结束的可交付增量是潜在可发布的，是否发布要依据组织的发布节奏。通常的发布节奏有三种。
在完成每个冲刺后发布：让发布和迭代的节奏保持一致。
在完成多个冲刺后发布：将多个迭代的结果合并为一个版本进行发布。
在完成每个特性后发布：不考虑迭代是否结束，做完一个特性就发布一个，这就是通常所说的持续发布。很多企业和公司完成一个特性后就马上向部分或者所有客户发布特性，非常频繁，有时可能甚至一天发布很多次。
制定迭代计划
迭代计划聚焦于实现本迭代所应开发的用户故事的详细任务以及任务的下发。一个迭代是一个较短的研发周期，通常持续2-4周。团队从产品列表中选择排序较高的用户故事纳入当前迭代中进行开发。制定迭代计划是为团队选择本迭代要完成的需求或任务。
每日计划
在每日站会中，团队成员聚在一起，每个人依次讲述自己在上次每日例会后做了什么，今天准备做什么，是否遇到了任何阻碍。团队通过每日站会的形式评估自己的状态，以一种非常直观的形式告诉大家当天计划做什么，这也可以让团队尽早识别风险。虽然早晨的这项仪式开始于对前一天的成果的讨论，但成功的团队会意识到每日站会是讨论计划的会议，而不是讨论状态的。因此，每日站会应该专注于制定一个每日进度的计划。
最后以图的形式总结在这些级别产生的工件及其相互之间的联系。
持续调整规划，保证产品的价值
在敏捷的整个层级规划中，是一个持续规划的过程，团队会不断根据过程中的所学所获来逐步完善计划；这种方法使团队在短期内就能明确责任，同时帮助他们了解自己的责任是如何推动长期目标的实现的。规划洋葱图的每一个层次都不止执行一次，而是在产品的整个生命周期中多次执行。不过，每层执行的频率取决于该层的位置。一般而言，最常规划的是较低的级别，随着向更高级别的迈进，你将逐步减慢你计划的步伐。比如说，你要经常、乃至每天做日常规划，但你可能只需要每隔几个月甚至一年才重新审视你的产品愿景。
在敏捷产品整个开发过程每个阶段都是持续进行的，结合开发过程图我们理解一下敏捷中的持续计划，过程图如下所示。
通过流程图可以看出，先制定一个前期计划，通常是当前迭代以及未来2-3个迭代的任务是明确的；然后尽早实现并发布给客户获取反馈；根据反馈及时进行计划，对前期制定的版本计划和产品路线图进行调整，不停的在前期计划和及时计划中寻找平衡，保证团队的目标始终是给用户带来价值，从而保证产品的价值。
敏捷规划的工具
时间盒
时间盒是固定的一段时间，相对比较短，计划的工作要在这段时间内完成。敏捷比较关注时间盒的概念，比如：一个迭代的时间盒是2-4周，一个迭代的计划会议是2个小时，一个回顾会的时间盒是1个小时，一个站会的时间盒是15分钟。时间盒的结束点可以视为一个检查点，采用时间盒的方式给整个敏捷项目的实施提供了频繁的检查点，通过结果评估、获取反馈、控制成本、管理风险来监控外界变换的不稳定的环境，从而测量进度并且重新计划进行中的工作。
渐进明细
渐进明细是一种滚动式规划的技术。 在PMI编制的PMBOK中，是一种对进度计划编制的技术，是指在项目进程中，随着信息越来越详细，估算越来越准确，持续改进和细化计划。细化是量化的基础，逐步细化我们的工作，可以提升项目计划的指导意义。
最小可售功能（MMF）
最小可售功能（MMF）是一个最小和可市场化的软件特征或者产品特佂，可以快速开发并为用户提供重要的价值。互联网时代的竞争中，第一个占领市场就可以抢占先机，即便这个功能可能还不完备，仅具备部分可用的功能。最小可售功能代表功能包足够完整到可以为用户或者市场提供价值，同时也足够小。在软件项目中，增量交付的方式让客户可以更早地获取可用功能，从而早期受益。增量交付在帮助团队获得早期投资回报的同时，也获得了早期的反馈，给后续功能开发提供了参考。
怎么样，各位读者朋友，鱼和熊掌是不是可以兼得啦。在敏捷的开发中也许你还有会这样或那样鱼和熊掌的问题，那不妨来华为云的DevCloud专业服务转转，这里不仅提供了解决方案还有各种能力评估呢！
在专业服务中针对不同的岗位提供了评估的能力，让开发者可以对号入座，并基于你所在的岗位、技术得到客观、全面、系统的测评以及名师般的学习引导。
快来访问专业服务平台，通过个人能力评估，看看自己是什么水平吧！
