scrum执行文档.doc

scrum执行文档
纲要
一、scrum团队的前提保证
二、scrum基本原则
三、scrum倡导的和反对的
四、scrum的角色
五、stand daily meeting（站立会议）
六、scrum的基本概念

一、scrum团队的前提保证
1、scrum团队的物质基础
>1、良好的薪酬福利（有竞争力的薪酬，明显优于IT界的平均水平）
>2、一个相对独立的环境（一个独立的办公环境，除了工作空间外，最好有可以进行stand daily meeting的空间，或小型会议的空间）
2、scrum对团队成员的要求：
良好的沟通能力，团队协作能力，良好的技术执行力，独立的模块分析和开发能力，良好的自学能力和英语水平，乐于分享，对scrum理念的认同。
（scrum强调的是团队成员的主动性和参与感，这个是团队执行力和效率的保证,关键在于良性循环）。
2、scrum团队的人员规模：
scrum最佳的人数规模4-9人，超过最大人数，会由于沟通成本过大，反而导致拖慢项目进度。
四、scrum的角色
Product Owner：项目所有人
scrum master：项目管理者
scrum team：团队成员（包括scrum master）

scrum daily meetting每日晨会（当然是站立进行），只允许猪发言，鸡最多只能旁听。
scrum team成员都是pig（猪），其他人是chicken（鸡）
这个叫法源自一个美国story
---------------------------------------
鸡想和猪一起做生意
鸡：我们一个开个商店吧。
猪：那卖什么呢
鸡：卖猪肉和鸡蛋
猪：不干，我是全身心投入，而你只是参与
---------------------------------------
只有scrum team成员（猪）才可以参与stand daily meetting并发言，如果有必要的话，其他人（鸡）只能旁听，无权发言和打断。
stand daily meetting（每日站会，站着会议的目的就是为了控制时间）
站会是纯技术会议，总时间<10分钟，每人<2分钟。
每人只回答三个问题：
1、昨天完成了什么
2、有什么问题和困难
3、今天计划做什么
站会的时间最好在早上10点进行，一是为了避免每天都是以一个会议开始以至流于应付和形式，二是留出时间给团队成员，以总结昨天的工作和进行今天的计划安排。
如果某成员发言时间过长，scrum master有权打断并结束其发言。
对于遇到的问题，如果其他成员有解决方案，可以提出，但不在站会中进行细节性的讨论，
在站会结束后，如果有必要，针对相关的问题，由scrum master组织相关成员进行小型的讨论，或直接协调解决。其他成员继续自己的工作。

scrum的基本概念
sprint（冲刺）：
scrum由多个固定周期的sprint组成，通常一个sprint的时间为1-4周，最长不能超过一月。
通常一个团队需要3-4个spring的适应时间，前2个sprint通常会不是很适应。

scrum的原则：
一周最佳脑力工作时间35小时（通常是双休+朝9晚5），所以scrum反对加班，如果有团队成员自主进行加班，最好不要超过半小时。
加班的人通常会觉得自己做的工作比正常的人多，但事实却恰恰相反。
对于加班的团队而言，在前两周工作完成相对有一定提高，但二周后工作效率急剧降低并一直持续，得不偿失。
就我个人经验而言，6个工作日的工作方式，通常至少有1-2天状态很差，不想做东西，强制自己去做工作效率又很低，而且缺乏灵感，不利于解决一些高复杂度的问题。
scrum开发通常每周固定一天由团队成员自由安排，可用来解决开发工具或其他方面的问题。
sprint之间应该有时间的缓冲，scrum成功的关键在于保持一个固定的节奏，而不是一味的冲刺，造成恶性循环积累。
scrum强调团队成员的自主感和参与感，甚至是主人翁精神。
开发时间的预计：由scrum团队通过计划纸牌产生。
原则是少数服从多数，但要给少数的发言机会（因为真理往往在少数人手中），以便做出合理的预期。
工作任务由团队成员自由认领，并接合scrum master分配灵活控制
代码审核：是scrum开发的重要一环，一是进行代码质量控制，二是提高团队的coding水平。

scrum的最高原则：
敏捷的是人本身，而不是我们去执行敏捷
所以，scrum的执行必须根据团队情况灵活应用，避免水土不服。
通常国外scrum团队成员的水平都比较高，scrum执行方式也相对民主一些。
国内的团队则参差不齐，因此，可以把scrum的管理方式和传统的项目经理管理方式相接合来进行。

scrum的核心原则：
积极面对变化，尽快交付项目，即每个sprint结束时保证项目处于可交付状态，这也是避免项目失控的关键。
敏捷的准确定义是：轻量级过程。
敏捷严格来说和开发速度无关，项目能否快速完成由团队成员的个人能力和协作能力决定。不过scrum团队的开发的效率都很高。
 ‍
‍
scrum的项目管理
1、Product Backlog（产品特性表：即原始需要，并对以上需要进行优先级排序）
2、Sprint Backlog （从上面的产品特性表中，按照优先级抽选出可以在一个sprint中完成的任务）
3、将spring Backlog中的任务由 scrum team成员自己认领，并完成相关特性的分析、设计、实现、测试
4、在sprint中保持每日daily meeting的进行 和 burn down chart（时间燃尽图）的更新。
5、完成一个sprint，当然对应的是一个可发布的版本（这个是scume成功的关键，保持每个sprint都有一个可运行发布的版本）
6、 每个spring的结束后，进行sprint review meeting（sprint回顾会议），由scrum team进行本次sprint的总结，关键是发现问题，解决问题，而非追究责任，scrum的理念是相信每位成员都尽了最大的努力的工作，并帮助团队成员 成长。
7、听取Product owner或客户的对当前产品的意见以及新的需求变化，新的需求和变化将加到Product backlog中并设置相应的优先级等待在后面的sprint中实现。
8、回去步骤2,循环进行，在新的sprint中必要的时候重构之前的代码以适应新的变化。

‍
scrum区别于传统开发模式的一点在于，每个spring结束后和下一个sprint开始前，接受需求的变化，即为一个调整点，所以一直比较接近成功的方向，风险相对也低。
而传统模式则在项目的最后阶段面临需求的变化时，变化的程度剧烈。风险高。

关于项目时间：
传统的方式通常都是预期一个时间，就像划了一条死亡线，如果项目时间预期不合理
（需求变化大或项目难度预估不足或预期时间本身就不合理等），为了赶进度，通常会造成代码质量下降、偷工减料等一系列恶劣后果。
scrum的时间预期通常是浮动的，随着项目进行会不断的调整，某一段时期内可能出现项目时间的增加，这都是正常的，但整体上是下降趋势的。