话说很多很多年以前，软件开发都是以“年”来计算的，需求3个月，设计三个月，开发一年，测试半年，改bug半年，上线之后发现需求没做对，刚开发的需求就已经欧蓝德了。
这个时候，敏捷开发(Agile)就应运而生了，它是由一位聪明”绝顶”的美国大叔Martin Fowler提出来的。区别于瀑布型开发方式，敏捷开发并不是追求前期的尽善尽美，而是力求在较短的周期内开发出产品的核心功能，尽早发布可用版本，在后续的生产周期中根据需求不断地迭代，升级和完善产品。
那么瀑布和敏捷，具体有啥不一样呢
瀑布模型的开发过程是有固定顺序的，并且每一阶段的的输入是由上一阶段的输出得来，也就意味着之前的工作没有完成，是不能够继续进行下一阶段开发的。因此，应用瀑布模型思想进行开发，虽然比较稳定，而且需求明确，但是其耗时长、任务顺序固定、越往后越难纠错、不能应对需求变化。另外，由于在开发过程中缺少周期性的产品校验，验收交付的成果往往与前期的需求相差甚远。
在敏捷软件开发中，测试是与编程在相同的迭代完成的，强调短期交付和验证。每完成一个迭代即产生一个可交付的产品，即便这个产品相对于上一个迭代只多了一小部分的功能增量，用户仍然可以使用这些新的软件进行价值验证，并依据验证判断软件的未来。敏捷不是方法论，不是开发框架或者过程，而是一套价值观，它要求团队关注最新情况，不断调整自己的计划满足当前的业务目标，做价值驱动的交付。
瀑布开发的方法只在最后时间交付，此方法使得风险逐渐积累和攀升，在交付时期达到顶峰。若相关方满意，则功成名就；若相关方不满意，则前功尽弃。而敏捷开发方法更注重需求的理解和改变，他在开发的过程中不断地修正对需求的理解，检查需求的正确性，使得风险逐层降低。
如何实践敏捷开发方法？！？
敏捷的实践方法有很多，SCRUM, XP(极限编程)，kanban, 等等。今天我们将结合微策略的管理体系着重介绍SCRUM开发框架。
SCRUM中定义了很多角色，这些角色被分成了两组：猪组和鸡组。这个分组方法来源于一则笑话：一天，一头猪和一只鸡在路上散步，鸡看了一下猪说, “嗨，我们合伙开一家餐馆怎么样？”，猪回头看了一下鸡说，“好主意，那你准备给餐馆起什么名字呢？”，鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样？”，“我不这么认为”，猪说, “我全身投入，而你只是参与而已。
微策略的“猪”组成员：
- Product Owner（PO）：确定产品功能，确定功能优先级，接受或拒绝开发团队的工作成果。
- Scrum Master: 作为团队的敏捷教练, 必须保证团队资源充分被利用和协同合作，解决团队障碍，做好外部借口，保证开发过程的正常进行。
- Scrum Team: 负责产品的研发工作，人数控制在5~10人，每个成员负责不同的技术方面并且有很强的自我管理和表达能力。成员之间必须进行充分的交流，形成可信任的关系。
在微策略，每一个scrum team都有一个PO，负责项目的优先级和每次迭代增量的确认。几个功能相似有紧密联系的scrum team会有形成Area或者division，由CPO，GPO或者APO来领导，一般拥有40~70团队成员不等。每一个division一般配备一到两个Scrum master，负责团队内部以及跨域的协同工作，团队障碍的清理，把握项目进度，及时发现并清除风险等工作。
微策略的“鸡”组成员：
鸡角色并不是scrum过程的一部分，但确实必须要考虑的。作为B2B的企业，微策略员工在日常工作中很少直接面对客户，PM(Product Manager) 在这其中起了非常重要的作用，也就成为了微策略最典型的鸡组成员。在项目的前期，PM负责市场需求和开发团队的对接；项目中期，通过周期性的开发汇报会议，确保开发工作符合市场或客户预期；项目尾期，PM确认产品交付。
角色确定了，那么我们如何实施SCRUM呢？
1、我们首先需要确定一个Product Backlog（产品需求列表），如下图（最左边一栏就是产品backlog）。PM和PO会根据市场需求，团队能力确认产品优先级和开发顺序，并计划在不同的release周期。
2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议）来确认每次迭代需要完成的目标，并在会议上对目标进行分解，行成spring backlog, 由scrum team去完成。
而实际上，在PO具体规划每个迭代的目标之前，会先组织团队进行tech spike和feature grooming，把feature分解，并根据公司release strategy制定大概的开发计划。这个计划往往是有一定的余度的，来应对开发中的不确定性。在微策略一般定义两周为一次迭代，每六次迭代（也就是3个月）进行一次产品发布。
3、每个成员根据Sprint Backlog再细化成更小的任务（Task）。微策略推荐每个任务不超过4个小时，最大粒度为8 hours，也就是一天。这样安排的好处在于对于大多数工程师而言，他可以每天对自己的任务进行总结和梳理，保存开发现场或者上传代码，有利于快速切换任务。
4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行Daily Scrum Meeting（每日站立会议），时间控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，承诺你今天要完成什么，遇到了什么不能解决的问题。微策略使用的敏捷工具Rally可以帮助绘出每次迭代的燃尽图（burning down chart）, 如果to do下降的速度太慢则有可能是加入了新的需求，或者开发遇到了瓶颈。Accepted的部分增长过缓，则本次迭代会有burnout的风险。
5、每一次迭代的完成，我们都要进行review meeting（演示会议）, 也称为评审会议。PM、scrum team、PO、SM都要参加，每一个Scrum Team的成员要向所有人演示自己完成的软件产品。成果的评审经常会影响下一次迭代的任务和目标。
6、最后一项内容就是Retrospective Meeting（回顾会议），总结并讨论改进的地方，产品的改进方案常常会被放入下一轮Sprint的产品需求中；在微策略，很多scrum team会把Retrospective meeting放在review meeting之后，除了讨论和总结产品的改进方案之外，成员也可以对团队的运行发表建议和意见，大家行程统一意见之后，会在接下来的时间内实施，这对新组建的队伍或者结对开发是有很重要的意义的，极大地缩短了团队的磨合期。
7、为了更好的敏捷实践，我们需要做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。除了要构建一整套自动化流程来保证构建、集成、测试、交付、部署的高可靠性之外，还需要各个团队开发强有力的自动化测试代码来保证每次迭代的可用性。微策略拥有自己的DevOps团队，来支撑敏捷实践下的持续集成和持续交付。根据CI/CD的设计，微策略的自动化流程包括了以下几个步骤：
- 提交：工程师根据当前工作内容向相应代码库提交代码。
- 测试：代码仓库对commit操作跑相应的自动化测试（pre-merge）, 测试成功后可以合并（merge）进主干, 然后进行第二轮测试(post-merge)。
- 构建: 将源码转换可以运行的代码，配置资源和依赖。
- 部署/交付: 将可以执行代码进行打包存档。在微策略，构建完成的代码会自动部署到某一个环境下执行各个功能点的自动化测试，严格的说，这并不属于持续集成的部分。但是由于微策略产品的复杂性，系统级别和端到端的自动化测试脚本能更好地检查产品的交付质量，所以往往在每次迭代后自动运行来保证后续开发和测试的稳定性。
它的好处是可以快速暴露错误，提高代码质量，降低整体集成风险，以及促进产品的快速迭代。
活学活用Scrum
微策略具有非常开放的企业文化，既会“拿来主义”，又会把方法本地化。大到一个division， 小到一个scrum team，每个团队都有自己对scrum独到的解读和实践。
比如，一个7~10人的团队，利用站会时间分享近期棘手问题的解决办法，新成员可以从这一短暂的分享中迅速积攒自己解决问题的能力。又比如，微策略的一些团队会在Retrospective meeting的时候给团队成员点一些下午茶，大家边吃边聊，开诚布公，每个人在轻松的氛围中更积极的参与问题的提出和解决办法的讨论。
由于团队的分工不同，每个时期的任务强度也有所不同。每天8个小时的plan对于很多团队来说很容易burnout，微策略的PO会根据不同时期的任务强度，市场的反应情况，为团队计划不同的工作量，以便更灵活地应对变更和紧急任务。
对于敏捷，大家诟病最多的就是文档记录的缺失。在我看来，这并非敏捷与生俱来的槽点，只是敏捷实践中并未对此做深入详尽的定义。文档记录也应该是因人而异，因地制宜的，每一个敏捷团队可以自己构建一套可执行的流程。在微策略，每当准备开发新feature时，Scrum master 团队会监督每一个scrum team完成四大文档（feature spec document, PD document, QA test plan document 以及UX document）并严格遵循review流程，保证文档的准确性和可读性。
还有不少实践敏捷的团队只是把瀑布中的开发过程截断成一个一个短的周期，其结果是每个迭代出来的都是未经验收的半成品，并未实现持续交付。更可怕的是，在没有确定当前开发的正确性之前，命令团队死磕到底把故事做出来，这种错误的打开方式会使团队产生误解，敏捷就是更多的COB和更频繁的加班。实则不然，正确的姿势是每个sprint都应该有一个小目标，团队需要估算能完成那些故事，约定好DoR和DoD，每一个迭代都应该产出业务价值，并得到确认。
SCRUM敏捷开发
给微策略带来的改变
1. 更快的市场响应速度：在瀑布开发模式下，微策略每3~4年发布一个版本，为了纪念千日等一回的激动时刻，我们用星星来命名发布的大版本，像Orion(MicroStrategy 9)，Polaris(MicroStrategy 10)。实施敏捷开发模式后，release的周期缩短到每三个月一次, 较短的迭代周期使团队快速进入开发状态。高质量的产品投放有效地刺激了市场，更及时的客户反馈减少patch的维护成本，促进新产品的开发和调整。（下图为11.2GA产品发布后给各个组分发的庆功零食）
2. 更强的质量保障：质量包含了两个方面，一是做正确的事，二是把事情做正确。微策略通过每日例会，review meeting对产品质量和进度进行检验，以便优化下一次工作目标的价值。持续集成结果快速反馈到开发小组以确认新产品代码的正确性，以便及时发现及时处理，减少错误增量交付的成本。
3. 更高效的自我管理团队：Agile 在组织形式上讲究自我组织，自我激励。在微策略，每个开发小组就像球队一样，当比赛开始的时候，前锋，后卫，中场，每个人在自己的位置上发挥自己的作用，而无需监管。每日例会和周期性的产品交付会帮助团队时时检查产品的正确性和价值增量，达到自治的状态。
开发方法千万条，适合自己第一条。敏捷和瀑布都是软件开发方法，没有孰优孰略。小编从业若干年，见过一些公司盲目跟风从瀑布硬转敏捷的，也见过把敏捷搞成小瀑布的，这都偏离了敏捷的初衷。想要真正趟出一条适合自己的敏捷之路，需要非凡的市场决断——天时，稳固的商业地位——地利，和坚定的团队实践——人和。说到这里，不得不为自己的公司赚一声吆喝：微策略看准了天时，占据了地利，赢得了人和，更欢迎优秀的你一起玩转“敏捷”！
我们会每周推送商业智能、数据分析资讯、技术干货和程序员日常生活，欢迎关注我们的头条&知乎公众号“微策略中国”或微信公众号“微策略 商业智能"。
閱讀更多 微策略中國 的文章
