Scrum和项目流程总结
最近所在的两个项目组都用到了敏捷开发Scrum，之前对它的理解更多的停留在自己工作涉及到的一些具体形式，比如Daily Scrum，工作量的评估等。对于Scrum是什么，为什么要用Scrum，一直没有去思考过这些问题，更没有做过深入的学习。前几天看到园子里的一篇关于scrum的博文（http://www.cnblogs.com/speeding/archive/2012/10/30/2746532.html），收获颇多，加深了对Scrum的理解。
Scrum的出现，我的理解是为了适应软件需求的频繁变化，以及满足客户尽快看到软件产品的需求。从网上搜索了一下对Scrum的定义，摘录了一个觉得解释最好的关于Scrum的定义如下：
- Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的、创新性的项目。（摘自：http://www.scrumcn.com/page/whatisscrum/index.php）
- 结合上文提到的博文中对Scrum的定义：Scrum总结起来就是3355（3455）：3种角色、3种工件、4种仪式（活动），5个价值观
- 3种角色：Product Owner（PO）、Scrum Master（SM）、Scrum Team
- 3种工件：Product Backlog、Sprint Backlog、Tracking/Increment
- 4个活动：Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective
- 5个价值观：Courage、Commitment、Focus、Respect、Openness
回顾一下之前所在的两个项目的工作流程，以下用P1和P2表示自己经历的两个项目。
P1项目：是一个完整的Scrum团队。包括1个PM，1个BA，1个Dev Architect，1个DBA，1个QA Lead，7个Developer，2个QA，这个是组织内部的人员，还包括客户方的Product manager。Scrum中的3种角色我们都齐了。感觉我们的项目应该算是传统开发模式和Scrum开发模式的一个结合，我们的角色和分工还是很明确的。
项目的运作流程：
- BA负责和客户方的PM、UX manager沟通需求，在JIRA上建立Requirement，形成初步的Product Backlog。BA再给组织内部的Dev和QA讲解requirement，同时大家一起讨论需求，BA再收集讨论结果，对于不明确的需求再和客户方进行沟通。通过和客户的几轮沟通（邮件、电话会议）确认最终的Product Backlog，并由Product Manager确认PBI的优先级。根据Product backlog的优先级选取当前Sprint的Sprint Backlog，并和客户确认。
- Sprint Planning Day：组织内部所有成员开计划会议，评估各自的工作量，分解任务，将每个可执行的任务分解到2天以内。
- PM发出Sprint Plan，大家按照计划，在JIRA上创建自己的task，BA负责维护requirement（即product backlog中的item，item还包括上一个sprint遗留的bugs），Dev和QA在每个requirement分别创建自己的Dev task和QA task。QA Task，我们通常包含write test outline, design test cases, test execution三个任务，其中前两个需要和BA、开发一起review，并update。
- 作为QA Lead，我会根据当前Sprint的Sprint Backlog制定Test Plan，确定测试范围、测试方法（测试级别、出入准则）、测试策略、测试进度计划、测试资源分配、测试风险分析。
- 开发发出Code Complete的通知，Release owner完成部署后，测试开始执行测试，提交bug。同时每天还要进行bug triage，对bug进行分类和排列优先级。正式的测试执行两轮，第一轮运行所有的case，第二轮运行新需求和bug fix相关的case。非正式的测试就是针对前两轮中failed的case，重新执行，再做一些adhoc的测试。
- 测试完成并符合退出准则，我会发出Test Report。BA根据Release owner的release通知和我的test report，编写sprint的release note，发给客户
- 客户的Product Manager根据release note选择需要发布到正式产品服务器的requirement和code change。
- 我们的scrum中没有用到burn down chart，而是直接利用Product Backlog完成情况跟踪项目进度
- Daily Scrum每天开，同时team成员轮流做meeting minute
- Sprint Review的话，PM会定期（通常是两天）和不同的角色进行相关工作的review
- Sprint Retrospective，在一个sprint结束后，新的sprint开始之前，PM会主持Sprint Retrospective，每人写三条项目中做的好的地方和三条需要改进的地方，不记名的写（这里有个插曲，由于我们组人不多，基本上大家的笔迹都能猜出来，所以会后的一个乐趣就是猜纸条都是谁写的）
总结下来，发现我们组的scrum貌似运行的还不错。
P2项目：我们是独立的测试团队，严格来说我们团队本身的运行算不上是scrum，但是从整个产品开发过程和与其他team的协作来看，有一些Scrum的元素在里面。整个测试团队有1个Test Manager，2个sub test team分别manual team和automation team，manual team有1个lead和6个tester，automation team有1个lead和3个developer。整个团队就是负责产品的功能测试。
项目的运作流程：
- 项目采用的是迭代开发，一个迭代一个月，三个迭代为一个周期称为一个Train
- 迭代开始，由销售在RTC上记录user story（通过市场的反馈获得），销售、需求、架构、开发、测试等的人会在RTC上讨论user story，并做comments，由user story的owner对user story进行update（这个讨论都是由经理级的人参与）
- 开发和测试分别在确定好的user story下，创建自己的task。
- Test Manager会针对每个Train制定一个测试计划，包括：
- 测试策略：定义Test Coverage（测试范围、级别）、Test Preparation（工具的选择、测试环境的搭建（服务器、客户端操作系统和浏览器的覆盖列表）、设计测试用例、测试计划和测试用例的review）、Test Execution（第一轮测试、Story的Regression test）、Test Report（测试执行记录、缺陷报告、周报、测试状态报告）
- 测试进度：定义重要的milestone（test preparation完成、开发code complete、第一轮测试执行完成、Regression test执行完成）
- 测试跟踪：通过user story和test task的映射，以及tester对于test task的实际执行情况，对user story的测试情况进行跟踪
- 测试资源和角色：定义测试团队的成员和角色，之前有所介绍
- build verification test：定义daily的BVT的目的（监控系统运行情况、验证最新版本被成功部署、24小时内获得反馈）和daily BVT的报告格式
- regression test：定义回归测试的目标和自动化对于回归测试的支持
- automation test：定义当前阶段自动化的目标、新的自动化的需求、自动化工具、自动化框架
- 风险和依赖：识别风险，并对风险进行分析，提出Mitigation plan
- Manual lead针对每个iteration的user story情况，分配user story给tester，同时按照Manager的测试计划推进项目的测试工作
- Tester在RTC的user story下创建自己的test task，包括write test outline、design test cases、test execution，前两项需要小组讨论、并发相应developer做review，然后由owner进行update。测试执行阶段运行test cases，提交bug，并就bug直接和developer进行沟通。
- Automation lead会针对Train制定automation development计划，主要涉及三个方面：Framework Improvement、Automation coverage和新的自动化需求。
- Developer会根据这个计划展开工作，在每个迭代进行维护自动化测试框架、开发新脚本扩大自动化测试覆盖、支持新的自动化需求。同时还要支持daily的automation regression test，以及测试阶段不同服务器上的automation test支持
- 项目进行过程中，Test Manager会和各种manager开daily的各种review meeting，包括bug的triage meeting
在P2项目中，由于整个项目团队有上百人，我们测试团队只是其中一小部分，所以整个项目角度的敏捷开发流程，对于我们测试团队的大多数成员来说只涉及到自己工作的一小部分。从Scrum的角度来看，我们应该不属于Scrum，但是有很多与Scrum相似的地方，比如需求的记录是通过user story，manager们会有类似于daily scrum的会议等等。
TAG:
