通过长沙银行行内敏捷开发管理几次培训，虽有收获但是未执行于实战，只能算是知识体系的一次再学习和补充，通过年终决算测试项目的实战实践的体会在这里做一下总结。
理解敏捷##
长行整个培训中一直穿插着敏捷软件开发的原则进行讲解，这里摘录给我感触最深的几个：
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意，经常地交付可工作的软件，相隔几星期或一两个月，倾向于较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
团队定期反思如何能提高成效，并依此调整自身的举止表现。
激发个体的斗志，提供所需的环境和支援，辅以信任，从而达成目标。
敏捷流派主要有两个：Scrum 和 极限编程。Scrum侧重项目协作流程，极限编程侧重提高编程效率的技术实践。两者应该相辅相成。年终决算测试项目更多的体现在Scrum上的应用。
团队与角色##
Scrum中有Product Owner、Team、Scrum Master三类角色。一个好的Scrum团队以下特点：
通常5~9人；年终决算测试重点内容分解过程、从开发、测试、环境保障、行内资源、行外资源、运维和业务几个维度确定主要负责人。
跨职能，跨模块人员构成；整个测试涉及到30多个主要系统和几十个相关协助系统的协同验证工作
成员应全职投入；根据测试需求和计划指定好全职投入人员，确保每一个指令下发后能第一时间响应
团队自组织管理；对于主要负责人集中办公，对于全职人员建立工作群，信息广播、提升问题协同响应处理的能力和效率
迭代内保持团队成员稳定。几轮演练测试人员基本保持稳定，测试目标和计划整体计划有序。
做好一个Product Owner要点如下：
定义产品功能；主要是定义测试范围和涉及相关的系统，另外调研出测试相关产品的功能完善性、有无待上线和未完成的需求。特别是影响年终决算的部分内容。
定义产品发布的日期和功能；制定好测试计划，每一轮测试目标，按时间点把需要人员排序好，让工作整体有序，资源得到充分的利用
对产品的投入产出比负责；对测试结果需要负责，确定测试目标的结果，并组织会议对每一轮结果进行回顾
根据市场情况对需求排列优先级；根据测试情况，对于需要重点关注、有疑问的测试结论重点排查，不放过每一个疑问，确保测试符合预期。
Scrum Master要引导团队自己去找答案，而不是做一个发号司令的人，做好一个Scrum Master要点如下：
Scrum正常运作的守护者；对于有困难的问题和工作环境做好协调
激发团队创造力；发挥每一个测试人员的主观能动性，每一个系统负责的项目经理的主观能动性，系统与系统之间的协调，通过群内广播的方式在工作中扩大自己的能力范围
改善开发团队的外部环境；测试环境、工作厂地、需要提到保障，
保持团队紧密合作；排除团队遇到的困难，特别是对于第一次参加年终决算的成员进行宣讲，对于重要系统的年终决算流程做好分享。
Team就是团队中的开发、测试或ui设计人员。
需求管理##
Scrum通过编写用户故事来管理需求，好的用户故事的原则如下：
Independent独立的；
Negotiable：可讨论的；
Valuable：对用户或客户有价值的；
Estimatable：可估计的；
Small：小的；
Testable：可测试的。
年终决算主要是测试工作量为主，在本次项目中并未能具体应用，后续在其它开发类需求中纳入实战，通过项目来理解需求管理，不脱离开发的基础上讲敏捷开发的应用。
Scrum中的各项活动##
按一个迭代周期来说，主要划分如下：迭代计划和评审一般要占用两个小时，而站立会议一般15分钟。
迭代计划1|
迭代计划2|
站立会议|
...|
站立会议|
迭代评审|
迭代回顾|
每一轮测试的主要环境准备、绿灯验证，指令执行，结果验证等环境做好准备活动，初始的用户故事列表、测试策略、测试计划等。
站立会议###
晨会的要点：
轮流发言，持Token者才可以发言；
不讨论深入细节；
不是对领导汇报，让团队中每个人都了解你的发言；
不能单独讨论，自发的有序的进行发言；
时间在15分钟以内。
站立晨会的三个经典问题：昨天我完成了哪些工作；明天我打算做什么；完成我的目标是否存在什么障碍。
迭代验收和回顾###
迭代验收会议，通过演示可工作的的测试结果是否满足客户要求；迭代验收的好处：
迭代回顾会议，目的是分享好的经验和发现改进点，促进团队不断进步，迭代回顾的好处：帮助团队挖掘优秀经验并继承，避免团队犯重复的错误、同时激励团队
利用敏捷改进现有工作##
即使不使用敏捷方式开发，也可以利用它的一些好的想法和实践可以用来提升目前的工作效率。
比如敏捷开发中如何调动团队积极性，让每个人看到的是团队目标，而不是个人目标。
比如借鉴敏捷中设定Sprint(冲刺)的开发过程，调动开发人员的积极性以及明确每个开发阶段的目的性。