前段时间参加了两天敏捷开发管理培训，收获挺大，在这里做一下总结。
理解敏捷##
整个培训过程中一直穿插着敏捷软件开发的原则进行讲解，这里摘录给我感触最深的几个：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意，经常地交付可工作的软件，相隔几星期或一两个月，倾向于较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 团队定期反思如何能提高成效，并依此调整自身的举止表现。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
敏捷流派主要有两个：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可以统计页面的访问次数，有了足够的数据支撑之后就可以把访问次数少的页面去掉，以此来精简文档，这样留下来的文档内容就是真正有用的。 -
业务部门的需求太多而且每个都非常紧急，怎么处理？
业务部门拉一个人对需求按价值进行排序；需求收集例行化，主动收集，需求有一定的清晰度；回顾哪些需求不重要，做为武器。