模板
教程
环境
性能
功能
管理
敏捷开发模型Scrum实施案例剖析
有一个项目也在实施Scrum，在我介入的时候，已进行到Sprint 9了。
当时的情况简述如下：
人员组成：1个Scrum master,1个Product owner,1个项目经理，1个主设计师，7个开发人员，2个随测试人员，随机2-4个系统测试人员。
工具支撑：
SVN进行配置管理
用脚本编写，搭建了持续集成环境
每日用EXL进行随测发现缺陷汇报与跟踪
CQ进行系统测试缺陷管理
白板贴纸进行任务控制
流程执行情况：
1月为1个Sprint周期
每月底25日左右召开上个sprint的回顾会议，下个Sprint的计划会议
每日召开站立会议(无系统测试人员参加)
系统测试根据业界成熟产品编写测试用例，执行测试
先记录到此，问题很多，下回分析。
这个项目运行将近一年，项目经理和Scrum master的能力很强，偶有线上问题，都能及时处理。项目有一定的风险，但问题不大，都在掌控中。
我作为QA，进入项目组，主要是观摩学习，看看项目执行Scrum的情况，并找出一些最佳实践供其他项目学习、参考。
了解项目现状后，我跟Scrum master进行了沟通，对发现的问题进行了探讨，摘抄部分，记录如下：
问题1：目前项目的组织架构与Scrum中设定的标准不同。
结论：1)项目中同一个Sprint运行了多个版本的项目，需要这么多人同时进行工作和协调，目前组织结构维持现状。
2) 因为场地原因，随测人员和系统测试人员不能与开发人员一起坐到一起。但需要参与项目的站立会议、计划会议和回顾会议。
3) 任务的完成以系统测试人员通过为准。随测人员和系统测试人员参与最初任务的估计，并在站立会议和白板上跟踪任务进度。
措施：1)在下次版本规划时，设立基础版本，版本进行分支管理，复用公共代码。
2) 项目的维护需求需要在计划会议前汇总给PO，进行需求的优先级排序。
3) 需求变更时，需要及时反映到product backlog中，并邮件抄送项目的相关人员。
问题2：白板上的部分任务没有计划时间和结束时间，无法跟踪进度的完成情况。
措施：1)在计划会议的时候，需要落实每一个任务的计划完成时间。
2) 任务实际完成后，需要填写实际的完成时间。
问题3：在Scrum works和白板上面的跟踪体现不出任务的增加和减少。
现状：目前完成了原计划的150H的任务，还有150H的工作未开始。
措施：1)从下个Sprint开始细化任务，所有任务要明确到人。
2)改变白板的布局，从现在的一栏改变为标准的白板格式。
3)新增和删除的要填写时间，或者用另外的便签纸表示。
问题4：目前是由小组长进行代码走查，未见实际的代码走查的记录。需要将走查发现的问题记录下来，大家共同学习，避免出现同样的错误。
措施：1)代码走查填写《代码走查记录表》。如果进度紧的情况，可以记录共性的问题和严重的个性问题，普通建议类的问题不需要记录。
2)记录一段时间后，形成项目组的编码规则和代码自查表，项目成员在编写代码的时候可以自查，以减少代码的低级问题和重复问题。
问题5：开发过程中文档很少，无法支撑测试组在前期进行测试计划编写和测试用例设计。这样开发和测试就成了串行的工作模式。目前是上线的版本非及时开发的版本，也有历史的测试用例和竞争对手的产品的情况下，这个问题反馈出来的影响还不是很大。但同样希望能引起重视。
措施：1) 在敏捷中强调测试驱动开发来避免这个问题，希望测试组的同学在这个方面进行研究，已适应演进式的设计和开发。
2) 在过渡时期，测试需要跟开发同步进行测试用例的分析和设计，测试完成后，需要进行覆盖率分析。
3) 与测试经理进行沟通，希望测试人员能进行敏捷培训，使用敏捷开发模式的项目测试需求。
项目在每个Sprint回顾会议的时候，都会讨论过程的改进点，经过5个Sprint的调整后，项目组织结构变化如下：
改进前：1个Scrum master,1个Product owner,1个项目经理，1个主设计师，7个开发人员，2个随测试人员，随机2-4个系统测试人员。
改进后：
1个Scrum master，负责Scrum流程的引导，扫清项目的障碍。
1个Product owner，负责在需求获取，product backlog的编写，需求优先级排序。主设计师和2个UI作为需求的输入人员，协助PO进行需求的澄清。
4个开发人员，1个开发人员负责基础版本维护和公用代码提取，另外3个开发人员各负责一个版本的功能开发和需求更新。
2个随测人员与项目组坐到了一起，应用Robot自动化测试框架，编写测试脚本，执行每日的自动化测试。
原先的项目经理进行产品的发布计划的制定和跟踪与项目外的协调工作。
原先的系统测试人员独立于项目组存在，依据传统流程，按照版本发布计划进行系统测试和上线的部署。
改进后的组织结构，在最近的2个Sprint中反应良好，相对改进前，更专注于各自的工作。
在以后的Sprint的回归会议中，将一如既往的听取团队的改进建议，如有不适合的地方，仍要继续调整。
持续跟踪中......
