上一篇浅谈敏捷开发及Scrum（一）概念与理解写了一些关于敏捷开发和Scrum的相关概念及个人理解，这里来说说实施与遇到的一些困难。
如何实施
敏捷开发的实施，我们是用的Scrum迭代开发，关于Scrum的一些介绍上一篇已经说了，这里说一下实施流程及其关键点。
一个Scrum迭代一般建议2-3周，具体视团队情况而定，一般团队中有一个PO，一个SM，以及5-7个团队人员（开发及测试，而且这里面最好有1-2个以上的多面手）。
迭代的管理，我们用的是leangoo，bug管理是用的禅道，下面是迭代流程：
Scrum迭代
1、Scrum开发中，所有的需求都需要进入到PO的Project Backlog；
2、在迭代启动前，由PO将里面的代办需求进行优先级排序，并整理成能执行的有价值的Story，移入Spring Backlog中（注意：这些Story是可执行的，PO一般应清楚需求的验收点，并对该Story有一个预估的时间点）；
3、在迭代周期内的第一天，这一天主要是进行项目启动会（需求评审、时间评估、实现思路及细节讨论、故事拆分、时间安排等），PO会对Spring Backlog中的Story进行描述，团队成员进行细节询问后，会进行一轮开发点评估（按团队成员进行一个增删改查业务为一个点来评估Story需要几个点进行开发或测试）；第一轮评估后，会由团队成员阐述评估时间点的原因，之后再进行1~2轮时间点评估。团队成员之间评估相近，且PO认为合理，取最终评估点最大值（注意：开发评开发时间，测试评测试时间）；如果最终评估点过大（我们一般取3以下的点，超过3则认为过大），需要进行Stroy拆分，拆分后继续评估；
4、所有Story评估完毕后，由团队成员自主领取任务，每个成员能完成的任务量参考之前迭代的任务量（一般是几个迭代后，才能比较准确的得到一个迭代团队和个人能顺利完成的任务点数）；
5、评估完毕后，当天，所有成员需要进行故事拆分，拆分为每天或者每半天能完成的任务，并给每个任务定一个时间点，一般是开发先定完时间点后，在开发的时间点基础上，测试再加上相对应的测试时间；
6、一般第二天或者第三天，会进行测试用例评审，这个主要是PO和测试参与，有需要时可让对应Story的开发人员参与；
7、每日站会，在迭代中，每天成员开始工作应该是先根据leangoo梳理每日的工作，然后在每日站会上叙述昨天完成的内容，今天计划做的以及面临的困难，是否需要支持（这个会议时间不宜过长，原则上是仅叙述，不实际解决问题，最重要的一点是PO闭嘴，因为PO一旦说话，肯定会聊到详细内容，然后整个团队的时间就浪费了。所以问题在会后解决，当然，更加提倡的时开发时候碰到问题立即解决，而不是等待每日站会）
8、项目验收会，在迭代的最后一天上午，我们一般会对项目进行验收，由测试展示给PO，由PO最终决定每一个Story是否达标，迭代是否顺利完成，这是PO的验收会，也是整个团队的成果展示会。
9、在最后一天下午，一般会进行迭代总结会，会评选出迭代之星，迭代中的优缺点，以及缺点的解决方案，并将解决方案分配到负责人，下个迭代努力去改进。
10、一般，在迭代中途，我们会有一些代码ReView，可以在成员的每次提交代码前进行update时看看别人的代码，并建议每周花一两个小时进行团队的代码ReView。
ps: 以上是一个迭代的主要流程（写得仓促，但愿没遗漏）。
需要注意的是：1、在迭代中，SM需要保证团队不收到外界干扰，所有的外界骚扰都先经过SM或PO，不能直接进入团队。2、PO需要在迭代前花费较多的时间来梳理清楚用户需求，才能让迭代更顺畅，不让等进入迭代遇到问题再去梳理用户需求。3、PO工作任务很大，责任也是最重的，必须保证一个迭代的任务是不轻易变化的，不得已非要变化时，需要进行Story替换。4、对于有线上维护任务的团队，视情况预留线上支持的任务点。5、如果有团队成员需要休假，最好在迭代启动会提出，并预留时间。6、团队的稳定性非常重要，团队稳定了，才能准确预估一个迭代能完成的点数，才能保证一个迭代顺利完成。7、迭代启动会对需求的讨论越详细越好，这样在开发中才能少进行错误的或者重复的工作。8、开发中有问题及时沟通，主张面对面沟通，不建议问题留到开会时解决，主张主动、积极。9、迭代总结会是很重要的，能让一个团队清除自己的长处和短处，而更重要的是持续迭代中对于短处的改进，这些将会让团队战斗力越来越强，迭代越来越轻松。11、迭代是为了更轻松更合理更及时的完成用户需求，所以强制给成员分配工作、频繁的需求变更等都不应该存在，这些会让迭代变得更沉重，让成员觉得迭代开发毫无生趣。
大项目实施
然而，一个大项目往往需要很多个迭代才能完成，那么，在大项目研发中，如何进行迭代呢？
这就需要将一个大的开发周期（几个月）拆分为一个个小的开发周期（2-3周），然后进行一轮轮的迭代；可以考虑在2-3个常规开发迭代后插入一个强化迭代（进行代码调整、问题修复、性能优化等），确保前几个迭代完成的任务能保质保量；在完成所有开发迭代后，再进行2-3个强化迭代（不断测试及修复问题、优化性能、优化用户体验等）；当然，最后还最好有一个发布迭代（用于整体回归测试、发布准备等）。
于是这个大项目的开发可能是这样的：
常规迭代-->常规迭代-->常规迭代-->强化迭代-->常规迭代-->常规迭代-->常规迭代-->强化迭代..........-->强化迭代-->强化迭代-->强化迭代-->发布迭代
遇到的困难
在迭代中，遇到一些困难时难免的，重要的是想着怎么去解决它，去保证迭代的正常进行，这样，迭代才会越来越顺利，任务进度才能有保障，成员才会越来越轻松。
1. 会议混乱，偏离主题
会议偏离主题，这个是我们团队迭代中存在了很长时间的问题，往往讨论一个问题，或者每日站会进行汇报时，随着一个成员的介入，主题越来越分散，最后甚至变成框架不支持、之前代码太混乱一类的抱怨。
- 针对这一问题，我们这样改进：
1.团队应该清楚任何讨论都是为了解决问题；2. SM应该把控好每一个问题讨论的范围，适当中止并引导回到主题；3. 在每日站会，PO绝对不允许发表任何看法，任何成员不能打断别人的叙述，有其他意见，站会后讨论；
2. 线上问题过多，干扰正常迭代
因为我们项目已经上线，而且主要是预约和缴费，所以线上有问题大多需要及时解决(毕竟对于用户及公司来说，涉及到钱的问题就是大问题），于是，刚开始的几个迭代我们做得很累，同时迭代也往往是以失败结束。
- 针对这一问题，我们这样改进：
1.根据上个迭代的经验，预留足够的任务点来作为线上支持；2. 所有线上问题先经过PO或SM过滤，保证开发人员不能被打断；3. 一些常规问题尽量让运维解决；4. 解决真正紧急且耗时不多的问题，其他问题留到下个迭代；
3. 外部原因导致迭代任务无法正常完成
因为我们有很多第三方的依赖，包括接口、资源申请等，往往在迭代中，我们完成任务，但第三方未能及时提供，导致不能联调甚至我们自己开发的一些步骤无法进行下去。
- 针对这一问题，我们这样改进：
1.在迭代开发前由PO确定好第三方能提供接口或资仅源的时间，降低任务的不确定性；2. 使用工具进行接口模拟，降低开发对第三方接口的依赖；3. 在迭代故事中，区分第三方的任务和我们自己的任务，将开发与联调分离；4. 当缺少第三方支持和资源时，主动及时提出，并找对方协商；
4. 测试无法融入团队的问题
在开发完成任务后，测试
5. 线上问题的管理
6.
简书：ThinkinLiu 博客: IT老五
关于敏捷开发，还在学习、实践及总结中，后续也会在这里记录新的问题和感想；如果有什么意见，欢迎共同探讨。
相关内容：
浅谈敏捷开发及Scrum（一）概念与理解
浅谈敏捷开发及Scrum（二）实施与难点
浅谈敏捷开发及Scrum（三）工具leangoo
浅谈敏捷开发及Scrum（四）工具zentao
