我觉得敏捷是一种工作方式，一种适用小而精团队的工作方式，好比特种兵，敢死队，《士兵突击》里的老A，人数不多、流程特殊、战斗力奇强。因此，敏捷对个人的要求极高，但绝大多数的人并不满足相应的要求，毕竟正规军永远多于特种兵，但是敏捷的一些方法、流程、思维方式依然可以引入到互联网企业里，毕竟，面对不断变换的互联网环境，小而精的团队团队拥有最好的适应力，而敏捷的文化正与之匹配；虽然不大可能打造一只由许多特种部队组成的特种军，但正规军的升级也能极大地提升我方的战斗力。

以下内容我是自己长期从开发和ScrumMaster角色参与敏捷，总结出的一些心得；由于这是我做分享时所用的提纲，所以对于各点没有详细的描述；但是，我相信如果你参与过敏捷，一定会从中有所收获；当然，未来我也会不断地充实它，争取把提纲变成一份完整的敏捷文化普及。

1、Scrum Master
1、不是领导职务，没有权利命令大家必须怎么做。
2、负责监督并推进敏捷过程的实施。
3、扫清敏捷过程中遇到的障碍。
4、保持敏锐的嗅觉，提前闻出过程腐朽的味道并进行解决。
5、牧羊犬而不是领头羊。
6、不一定是职位最高的人。

2、会议
1、迟到？
解决迟到问题的关键不仅仅在于建立什么样的监督制度，更重要的是要让会议开得有意义，要让每一位参会者觉得有意义。
2、形式
1、必须要有会议主持人
2、会议主持人有义务设定会议议程及时间盒子，并在会议开始前通知所有参会者
3、会议参会者有义务依据会议议程做出准备
4、合理邀请参会者（必选，可选）
5、充分利用白板（讨论）而不是投影仪（演示）
3、安排
1、总结会，下期迭代冲刺会之前，比如上线当天上午
2、演示会：总结会之前
3、总结会与冲刺会间隔一天，冲刺会的当天不排入迭代开发周期，冲刺会安排在上午进行，下午用于大家为迭代开发的开始做准备，如制定开发计划、测试计划、需求录入QC，给出各项关键时间，排除所有影响开发开始的障碍。

3、白板
1、尺子画：你对白板认真，白板才会对你认真
2、去除两列（NOT DO、【TO DO】、【HTML】、DEVING、TEST、UAT、PASS）
3、统一纸张大小
4、用户故事五要素（内容、DEV、TEST、业务、CC）
5、分角色测试用特殊颜色标识
6、新增用户故事需与正常的区别开

4、站立会
1、意义：让团队之间的工作变得透明，让大家知道每一个人已经完成了什么，打算做什么，有什么问题，需要什么样的帮助；从某种程度上说，也是一次team building。
2、实践：
1、Scrum Master宣布会议开始
2、产品经理分享昨天的简要数据（销量，CVR，其他值得分享的数据）
3、各个参会者轮流讲话，主要围绕四点（已经完成了什么，打算做什么，有什么问题，需要什么样的帮助），允许适当变通调整。
4、Scrum总结并负责记录会议要点（包括需要跟进的问题及跟进人），会后更新WIKI并发邮件通知。
5、如果领导参加，并有事情通知大家话，放在最后进行。
3、注意：
1、如果有复杂问题的话即时安排人跟进而不是在会上讨论。
2、不要开小会。
3、控制参会人数及时间。

5、用户故事
1、怎么写？什么时候写？谁写？
2、怎么写？
不断学习，改进
3、什么时候写？
1、冲刺会之前，与开发、测试讨论需求的时候就应该有一个初版
2、开发对每个用户故事估时
3、冲刺会时针对用户故事讨论而不是详细的计划
4、每次backlog中增加一栏针对每个用户故事的CC时间
5、开发各自沟通安排开发计划，由一名开发负责按用户故事合并并更新backlog中的CC时间
用户故事在开冲刺会前写出，与开发、测试讨论需求时就应该拿出初版，经开发、测试协助完善，冲刺会上一个故事就是一个可拆分的单元。（理论上，前提是用户故事写得正确，实际时可适做调整）
4、谁写？
开发写的话就变成开发任务了。
客户团队（产品经理为主、开发、测试辅助）

6、学习
1、自成长团队
2、自发
分享人和参与人都要充足的准备
3、积累
WIKI、独立网站

7、其他
1、平等、信任。
2、敏捷过程的改进也是迭代式的，找出关键点，排定优先级，用敏捷的方式处理改进点。
3、迭代目标有两种，业务目标和敏捷改进目标，每日站立会后在总结邮件中一并发出提醒。
4、假日后的第一天容易积累问题，更需事先准备。
5、迭代提交，测试、UAT尽早介入。
6、需求调研会？需求调研任务？
7、文档如果用来沟通，它就是罪恶的；如果用来备忘，它就是美好的。

阅读(3973)