最近一直在了解和学习敏捷开发的应用，主要学习的还是Scrum。写这篇文章也是为了能对这段时间的学习有个总结。
在谈Scrum之前，我们可以先简单了解下敏捷开发。
维基百科是这样解释的，敏捷开发是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
敏捷开发注重以人为本，拥抱变化，目标明确，每个人资源相匹配。
敏捷软件开发法支持广泛的软件开发生命周期。比如极限编程更专注于实践，Scrum、看板则专注于管理工作流程。
接下来我，我们再说说Scrum。
上面也提到过， Scrum相对来说专注于管理工作流程。对在每一次冲刺或迭代（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个迭代所要实现的功能来自产品订单。产品订单按照优先级排列工作需求。在迭代计划会议中，产品负责人告诉开发团队需要完成产品订单中的哪些订单项。开发团队决定在下一次迭代中他们能够承诺完成多少订单项。[4] 在迭代的过程中，没有人能够变更迭代订单，这意味着在一个迭代中需求是被冻结的。
Scrum 包含三个重要的角色：
-
Scrum Master 是Scrum教练和团队的引导人，也是保证整个过程能够合理动作Scrum的核心角色，并且能够扫清团队实施遇到的困扰。
产品负责人 确保产品的方向，定义产品优先级、交付时间及产品的商业价值，是整个团队中的指明灯。
开发团队 是具体执行者。交付产品所需要的各种技能的拥有者。
这三种角色组成了Scrum的最小单位。
在团队开发过程中，关于会议一直是有争议的地方。我接触过很多团队，一种是整个开发过程中只有里程碑或者到某个时间节点时才会全员坐在一起进行某种意义上的交付，另一种则是三四天会开一次，每次时间则在1个小时左右的时间。
对于Scrum来说， 会议是整个过程中重要的一环。Scrum主张“每日站立会”， 要求每天的同一时间和同一地点进行15分钟以内的站立会，而每天这个会议有一个永恒的主题：
-
昨天完成的工作
今天打算完成的工作
完成工作中需要协助的地方。
这也是由于Scrum的一个重要特性，我们必须能够掌握每个环节的状态，确保整个项目链能够在我们的风险控制内。每个人目前的工作内容，计划都公开透明，最大程度的饱合了工作，同时也把风险及时的暴露出来，能及时调整、规避或者解决问题。
对于实施Scrum来说，上面也最关键的有两点特性：
-
拥抱变化。客户或者需求方可以在项目过程中改变主意，变更他们的需求，而这些不可预见的因素是确确实实存在的，而如何快速响应不断变化的需求和快速推出产品也是对整个团队能力的一大考验。
快速迭代。在使用Scrum时，每次发布都是一次里程碑，在这个变化多端且竞争激烈的时代，没有任何产品能够忍受半年或者一年全部需求做完后，再去发布版本。所以，我们也能想像到，每次scrum都会不断精简需求，宁可先做几个简版上线，也不愿意在做完所有功能再上线。
这两点特性，也间接的证明了，Scrum的高容错率和专注性。每个团队不可能保证不犯错误，而scrum的快速迭代及周期短，从而保证小的错误能够被尽快的发现，而不是等到需要付出一定代价才能解决的错误。
所以， 在实施Scrum时 经常会强制性的规定周期来做Sprint。这种形式充满了不确定性，但是却又大大提高每个角色的专注度。如果我们非要事先确定发布周期而且还需要保证需求或功能不能有任何删减，那么，这种模式是真的不适合Scrum。
说了这么多， 主要还是在流程上尤其重要，有些环节看似烦琐，但却是不可或缺的一步。而在这些环节上都隐藏着一个重要的角色： Scrum Master。
为什么单独拿出Scrum Master来说呢？我看了很多参考资料和书，也问了一些人，发现Scrum Master或许是整个开发过程中职责最不明确但却最重要的一个角色： 不参与需求分析、不参与代码开发、不参与产品调研。他的职责只有两个：
-
保证流程的正确执行以及项目的风险控制。
扫除一切其他人员遇到的障碍。
所以，这是一个存在感很低，你很容易忽略但又不能不存在的角色。Scrum Master 关注的不仅仅是某一项工作或者某一个人，他需要关注团队中的每一个人，团队中的每一项工作，遇到的每一个问题。这个角色不一定要懂开发技能，也不一定要有产品技能，但它一定会真正理解团队的痛点，它的选择永远是对团队有利的事。
接下来，我们再简单的说下这方面应用的工具。
传统的Scrum，会用白板和Excel等工具。而现在各种云上的第三方协作工具也比较广泛，为避免做广告的嫌疑，我们就不提具体的第三方协作工具了。使用工具遵循的原则是：
-
简单。能够快速上手、使用方便
流程化。便于流程化管理，衔接性比较强
透明。 每项工作能够对内透明
统计图表。不解释
说了这么多，也需要解释下，并不是所有的项目都适合Scrum。一般使用Scrum最好能符合以下几个特征：
-
时间有限，日期比较紧迫
市场需求或者技术变更很快
实验性的项目
项目很复杂，并且灵活性较强
最后，再附上一张Scrum的流程图
注： 图片来源于网络，如有侵权请联系作者，进行删除。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。