参加Scrum中文网CSM课程收获
软件开发从2000年之后开始流行一种新的开发模式，本人也是关注这类的书籍，平时在项目中摸索着尝试用敏捷。但是始终没有系统的学习。因此借着最近一段时间项目不忙，系统的参加了Scrum中文网（www.scrumcn.com）的CSM课程，感受蛮多。
理解敏捷整个培训过程中一直穿插着敏捷软件开发的原则进行讲解，这里摘录给我感触最深的几个：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意，经常地交付可工作的软件，相隔几星期或一两个月，倾向于较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。团队定期反思如何能提高成效，并依此调整自身的举止表现。激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
敏捷流派主要有两个：Scrum 和 极限编程。Scrum侧重项目协作流程，极限编程侧重提高编程效率的技术实践。两者应该相辅相成。
这里着重讲讲Scrum。团队与角色Scrum中有Product Owner、Team、Scrum Master三类角色。一个好的Scrum团队以下特点：通常5~9人；跨职能，跨模块人员构成；成员应全职投入；团队自组织管理；迭代内保持团队成员稳定。做好一个Product Owner要点如下：定义产品功能；定义产品发布的日期和功能；对产品的投入产出比负责；根据市场情况对需求排列优先级；如果需要，在每个迭代合理调整产品特性及其优先级；介绍或拒绝开发团队的工作成果。Scrum Master要引导团队自己去找答案，而不是做一个发号司令的人，做好一个Scrum Master要点如下：Scrum正常运作的守护者；激发团队创造力；改善开发团队的外部环境；辅导团队提升运作效率；排除团队遇到的困难；保持团队紧密合作；Team就是团队中的开发、测试或ui设计人员。
需求管理Scrum通过编写用户故事来管理需求，好的用户故事的原则如下：Independent独立的；Negotiable：可讨论的；Valuable：对用户或客户有价值的；Estimatable：可估计的；Small：小的；Testable：可测试的。之后要进行工作量估算，Product Owner(业务人员)必须在场梳理需求，每个项目成员针对用户故事的疑问向Product Owner提问，所有人弄清楚需求后开始。大家先找一个参照需求，确定它的工作量，然后其他的需求就按照这个参照需求来估计，这种相对估计法确保每个人估计出来的工作量是一致的。使用扑克牌，大家同时给出需求的估计值（而不是轮流进行），估值最高和最低的必须分别给出原因，这样做的好处让大家都独立思考。通过多轮估值让所有人了解需求，并估算出一个较为合理的工作量。
Scrum中的各项活动简单来说，划分如下项目计划|Sprint0|Sprint1|Sprint2|Sprint3|项目总结|按一个迭代周期来说，主要划分如下：迭代计划和评审一般要占用两个小时，而站立会议一般15分钟。迭代计划1|迭代计划2|站立会议|...|站立会议|迭代评审|迭代回顾|Spint0要做一些准备活动，如高层的业务流程图、初始的用户故事列表、测试策略、发布计划、团队建设、技术架构的选择、设计UI的风格等。站立会议晨会的要点：轮流发言，持Token者才可以发言；不讨论深入细节；不是对领导汇报，让团队中每个人都了解你的发言；不能单独讨论，自发的有序的进行发言；时间在15分钟以内。站立晨会的三个经典问题：昨天我完成了哪些工作；明天我打算做什么；完成我的目标是否存在什么障碍。站立晨会的目的不是为了让大家都回答那三个问题，而是让团队围绕这三个问题，制定当天的工作计划并暴露问题。迭代验收和回顾迭代验收会议，通过演示可工作的软件检查需求是否满足客户要求；迭代验收的好处：通过演示可工作的软件来确认项目的进度，具有真实性；
能尽早获得用户对产品的反馈，使产品更贴近客户需求。收集反馈。迭代回顾会议，目的是分享好的经验和发现改进点，促进团队不断进步，迭代回顾的好处：激励团队成员；帮助团队挖掘优秀经验并继承；避免团队犯重复的错误；营造团队自主改进的氛围。利用敏捷改进现有工作即使不使用敏捷方式开发，也可以利用它的一些好的想法和实践可以用来提升目前的工作效率。比如敏捷开发中如何调动团队积极性，让每个人看到的是团队目标，而不是个人目标。比如经常地交付可工作的软件：以此提高软件开发的质量和可交付性。比如借鉴敏捷中设定Sprint(冲刺)的开发过程，调动开发人员的积极性以及明确每个开发阶段的目的性。其他问题需求文档 或者 使用说明文档 写了100多页，但是写完之后基本没人看，这样的问题应该很普遍，该如何解决？把Word文档迁移到Wiki上，大文档切细分成一个个独立的Wiki页面，Wiki可以统计页面的访问次数，有了足够的数据支撑之后就可以把访问次数少的页面去掉，以此来精简文档，这样留下来的文档内容就是真正有用的。业务部门的需求太多而且每个都非常紧急，怎么处理？业务部门拉一个人对需求按价值进行排序；需求收集例行化，主动收集，需求有一定的清晰度；回顾哪些需求不重要，做为武器。
