浅谈敏捷开发及Scrum：概念与理解

接触“敏捷”这个词有蛮久了，团队近半年也在实行敏捷开发，对于敏捷也有一些感触…

啥是“敏捷开发”

对于“敏捷开发”，网上有很多解释，可以查到一大堆相关文章，而且很多文章都有自己的不完全相同的解释；啥是“敏捷开发”，我也无法给出标准答案，这里只谈谈自己的看法：敏捷开发是以用户需求为导向，需求进化为核心，采用迭代、逐步完善的方式进行软件开发；其中的核心是“用户需求进化”与“迭代、逐步完善”！前者保证我们所做的工作于用户（包含终端用户、产品、领导、实施、研发等所有提出合理需求的人）而言是有意义的（或者说有商业价值的），后者保证需求开发的有序性、并在一定周期内的研发工作不会被打断。

另外，很多人以为敏捷开发就等于Scrum或者XP，但是，这些还是有所不同的，敏捷更多的是一种思想，而Scrum是敏捷开发的一种实践模式，也可以说是方法～（我是这样理解的，不知道有没有错误）

Scrum迭代

“敏捷开发”实施其实说起来很简单，然而，我接触的实施“敏捷开发”的几个团队对敏捷开发的反响却不尽相同，有的团队觉得敏捷开发确实能让团队更有战斗力；有的团队认为敏捷开发拖慢了团队开发的节奏；也有的团队觉得敏捷不敏捷其实都一样。

这些团队对敏捷开发的实施方案都是“Scrum”迭代开发，那么，首先我们来了解下“Scrum”，“Scrum”是一种迭代式软件开发，包含SM，PO，TEAM三类角色：SM是指团队管理者，最主要的职责是维护团队的稳定性与不受外界干扰；PO即产品，主要职责是需求的整理、优先级排序、内部验收等；TEAM，指整个团队的开发人员，主要职责是研发与测试。

“Scrum”主张一切从简，少文档（一切皆文档，会议纪要、会议白板等都作为文档，而不必再另外整理标准文档）少会议，及时沟通；但是，它也主张几个必要的会议：1、启动会（需求评审、用时评估、故事分配、任务拆分、承诺完成时间）2、每日站会（前一日完成任务，今天计划完成任务，任务进度与面临的困难）3、评审会（团队迭代周期成功的展示与验收）4、迭代回顾会（迭代中的优缺点，改进方法，改进方法的实施）；另外，还有一个非常必要的，决定迭代是否能正常进行的事件：产品梳理（PO梳理接下来1~2个迭代周期的任务）

"Scrum"主张公开，专注，勇气，承诺，尊重；我的理解是：信息沟通及时，无阻碍；三大角色职责分明；用于选择及领取开发任务；为任务作出合理的时间承诺并完成；团队内部无阶级区分。

“Scrum”的一些其他问题就先不说了，其实这些网上一大堆，上面只是我对自己认为比较重要的几点内容的理解。

再回到最初说到的不同团队实施敏捷开发后的看法；从上面，我们不难了解到，在“Scrum”中：PO对故事的优先级排序，提前准备，对迭代周期内故事的安排；SM对团队的保护；团队对任务的拆分，对承诺时间及内容的忠诚度；对迭代内问题的处理及时性；团队的稳定性等等……这些都会对其成功率产生很大的影响。以上问题，一般是在迭代中，某一项或几项出现了问题。

其实准备写“敏捷”已经很久了，但网上已经太多类似的文章，而且不尽相同，我也担心自己写错误导别人；但是，后来一想，也许有大牛能帮忙纠正呢，可以逐步加深理解。所以，就准备记录发布了，大家带着怀疑的精神看，有不同见解欢迎一起探讨…

ps: 先记录对敏捷和Scrum的一些基础理解，后续再补充“如何实施”与“遇到的困难”…