严格来说，不能算是真正的scrum实践，但实践敏捷的过程本身也是一种“敏捷方法”，所以就算是“敏捷实践之敏捷开发方法－scrum过程”吧。
一、理论参考：Scrum的实践（该部分摘自网络）
1.Scrum团队（5-7个人的小项目组）。
2. Backlog: 急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。
3. Sprint(冲刺): 通常为30天的迭代时间，把Backlog中的每一项安排在Sprint中，由团队估算出所需要的时间（按小时记）。每一次Sprint之后，一定要有可以交付使用的功能。
4. Scrum会议: 这是与传统方式最大的区别，每天15-20分钟的Scrum会议，通常在每天的同一时间和同一个房间内举行(通常在午饭后举行)。
Scrum团队所有人都参加，也可以有旁听者（但不允许旁听者指手划脚）。在这个15分钟的会议上，Scrum
Master会询问每个成员三个问题:
a) 自上次Scrum会议后的1天里你做了什么？
b) 从现在到下次Scrum会议的1天时间里你准备做什么？
c) 你在工作中遇到了哪些困难？
每个成员在Backlog条目上所花费的时间会被记录到Spring backlog中。 Scrum Master在会上对存在的问题提出即时的解决方案或指导，使团队不断向着目标前进。Scrum会议不同于项目会议，对团队来说，它起到了快速简报的作用。
5. 通过Sprint Backlog的分析，可以了解Backlog的进度，尽早的了解所发生的问题；
6. 管理者不在是项目或者团队的``老板", 而是帮助团队解决问题的协调者或是助手；
7. 每一次Sprint之后要review，团队按照既定的Sprint Backlog目标来演示完成的内容。
二、实践小记：
1．目前的团队刚好7人，且项目背景提供了可实践scrum的良好土壤；
2. 小版本迭代：从项目启动开始，采用最多不超过３周的阶段计划；各个阶段根据情况发布系统内部版本；
注意与传统方法区别，没有按固定周期月之类定计划，而是按目前能预见的周期内定计划。事实也是如此，根据几个月的实践经验，最多只能预测三周。
3. 每次阶段计划的时候：功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，先从各成员处收集汇总成为项目任务，并以半天为单位，预估工作量；集体讨论确定优先级，然后排工作量，优先级低的任务被去除；
可惜的是无法做到让客户来帮我们定优先级；
不过期间我们通过“现场开发”（与客户方常驻一起）的方式，尽量让客户每天能看到系统，提出修改意见；实践证明，这种开发效率的确要高很多。
4. 每次阶段计划末：统计上个阶段每个人任务完成情况、团队阶段任务完成情况、成员工作自我评估满意度等，并在一个较大周期（一般是3月5日个小阶段）后绘制统计曲线；
注意这个曲线一方面可作为项目绩效参考，一方面也能够清楚反映项目计划、进度控制中的各种问题；
5. 每周都进行有1－2次进度沟通（每次２０－３０分钟）：互相了解开发进度、遇到什么问题如何解决，需不需要调整细节计划、内部调整；其中一次是随机的，一次是固定的，每周五例会。
注意，在周五例会的时候，除了正常的工作沟通，还会进行心情指数、压力指数调查，并安排相应的娱乐活动，关注每个成员的情绪状态和满意度；
关于心情指数，压力指数，工作满意度等也会在一个大周期后绘制统计曲线，作为项目阶段总结，以持续改进；
其实每周例会最忌讳的是“公事公办”，应该尽量随意点，成为大家坦诚沟通的平台，谈工作，谈生活，发牢骚，情绪宣泄越畅快越好；有条件就到室外去开。
后来我们在周例会中还加入了３０分钟技术交流时间，轮流有人自发就本周工作中的体会或经验进行简短技术交流，不用花太多时间准备，但对团队知识积累非常有益（交流完了，资料要求进入知识库）
6. 核心任务，或项目中的关键路径，采取更紧凑的日进度沟通：通常是对里程碑任务和新加入成员，采取日进度沟通。形式上不是“站立式会议”，多以该面对面随意聊天、或即时消息、个人或团队工作日志进行。
个人更推荐随意的面对面聊天，更符合我们的习惯，主导该关键任务的人，每天 早上来了，跟任务相关的人打打招呼：
“ｈｉ，搞定了没？”
“这么快啊，你家伙很厉害嘛。。。”
“哦，请假了啊，没关系的，先让××帮你看看。。。”
通过这种很随意的方式，即达到了进度沟通的目的，又让大家觉得亲切如朋友。如果太严肃，反而会隐藏很多问题。
7. 持续改进：一般在3－5个阶段过后，往往会进入项目下一“新进程”，这个时候把前面所有的进度统计、成员满意度统计、问题跟踪统计、技术问题等资料统统收集起来，进行分析总结，并确定下一阶段的改进措施和工作目标。
问题和改进措施非常重要。一般的做法是让每个人都提3-5个认为团队工作最需要改进的方面；然后集体再去排优先级，讨论可行的改进措施，然后制定成问题改进跟踪表（有个软件平台最好），到下个进程再循环；
以我们的实践经验，只要前面做好了，这份总结很容易，半天就可以整理好。
总结中一个非常重要的方面，就是对成员的管理。这个大阶段内，有人进步非常快，有人一直承担核心任务，有人总是赶在进度之前（是不是下次应多分配点任务），有人进度延迟较多，满意度也不高（是不是个人情绪问题，生活中有什么事情影响了工作？）
针对这些情况，私下里或正式或随意的面谈沟通非常重要。不解决好人员问题，后面就有很多不可控的风险。
8. 人员管理为核心：团队成员角色识别、个性搭配、技术能力搭配、团队成员技术发展目标和能力发展目标，及时面谈沟通等。
“授之以渔，非授之以鱼”：任何能够让成员提高的事情，都要绝对遵循这个原则，哪怕相对要花较长时间，但绝对是值得的；任何团队都会受制于很多现实条件，或许团队里面有2个猪八戒，或许团队里面除了一个孙悟空，其他的都还不及沙僧，或是人员变更，这都是不可避免的，所以要提前做好预测，识别团队角色上的缺陷，尽早进行培养，才不至于落得被动。
关于成员发展问题，以前的太简单了，好像成员就是发展为项目经理，这就叫职业规划了，其实完全不对路。团队里面，当确定目标的时候，一定要从小处入手：如技术方面，某一方面的技术能力获取突破成为公司专家；某一技术弱项快速提高，达到中等层次；知识面拓宽；
如工作能力方面：语言表达、沟通能力达到团队最好水平，文档能力达到团队最高水平；如角色方面；发展为技术管理角色；发展为集成员和质量保证角色；发展为管理角色等。
这种发展目标实实在在，每个人都能很快看到自己的进步。当然，如果某位成员有成为项目经理的机会，也要鼎力向上级推荐。
9. 关于“结对”编程：在某些关键任务的设计、调试阶段，采用结对方法；
另外：新成员学习期间，每天有1-2小时的结对时间；项目进行单元测试期间，“变相结对”，首先：交换测试（你实现的我测，我实现的你测），然后共同解决问题。
10. 其他，针对项目经理：
1) 你是否还在当“队长”，而不是当“教练”？你是否还在“管事”，而不是“管人”？你是否还在惧怕你的成员能力超越了你？如果是，后面都不用看了，无法做到的。
2) 要做到前面所说，前期铺垫是非常重要的，你的团队成员都接受了你？你是否已经初步和他们建立了坦诚、同甘共苦的合作关系？
3) 你是否真的花了70％的时间在沟通和协调？
4) 你的团队角色都选好了吗？你的工作是否得到了上级支持？
5) 你是否总是主动向客户和上级汇报工作进展，书面的，面对面的？
6）你是否持续用分解的小目标来鼓励士气？
7) 是否经常在小目标达成之后通过各种方式激励大家（公布问题改进跟综表让大家随时看到团队的进步？一起活动，上班期间半小时聊天休息，邀上公司领导一起聚餐）
8）除了工作外，你是否了解每个成员的个人生活状况，并随时能灵敏感觉到部分成员的消极情绪？你是否尽全力帮他们解决了工作上，甚至生活上的问题？
9) 在去除某个资源障碍时，你是否真正做到了绝对客观和问心无愧？
比较有意思的是下面这段话：
@肯.索夫特
我在的公司的确不大，而且关键是我的上级是一个非常好的领导，我的想法他总能一听就懂，并给你空间，支持你；
心情指数和压力指数调查肯定不会是填表，例会的时候大家自己说；
我想真实度是依赖于你前期所作的工作，是否真正让大家相处得象兄弟姐妹一样；
而且某些情况下是70或90哪个更准确并不重要，重要的是让大家有机会表达；
关于上班时聊天，不难操作啊，我想大多都有周例会吧？为什么不能在工作说完之后，让大家随意聊聊呢？呵呵，我们有个优势，就是周五的时候会议室不够用，所以偶尔情况下，刚好有借口在办公室外开会，大家心情放松多了。
@samever
大公司流程管的严，是难操作些。
“高深”的理论向来都不能“武装”人，只能吓跑人，所以我从来没在我的上级，或是同事之间说过，我们要“Agile”,“scrum”，或“XP”，或“pair”。
我说：“头儿，我有些内部管理的想法想在我们项目中尝试下。”
头儿说：“可以啊，没问题”。
我说：“上次项目总结大家提的问题不是都说‘计划赶不上变化’吗，那我们现在能不能尽量把周期缩短点，能预见多长，就定多长的计划呢？”
大家点头：“对，是该试下”。
我说：“××，你看看是不是我们俩在一起研究下这块的代码”？
然后结对开始了。
公司外部版本发布，要严格走流程，我们就不停采用内部发布，这样一点一点小版本就出来了。
。。。。。。
其实在之前，我们在项目的管理上也是跟着感觉走的，一笔糊涂账；
但只有这样细致、日常积累数据，才能真的“管得清楚”（怎么想起小燕子的“跪得容易”了，；） ）
| 
