老翅寒暑

项目管理沙龙第十二次会议纪要

本次会议的主题是为没有敏捷共识的项目组定制一个敏捷的实施方法。这是一种普遍存在的情况，和其他的新事物一样，总会有一些人对“敏捷”这两个字比较敏感，究其原因，无外乎偏见、误解和不了解（无知），部分人则是恐惧或自大。当然，不了解是绝大多数人的原因。

但是，面对“没有共识”的人们，到底是说服之后再实施敏捷呢，还是先实施敏捷再用实际效果展示给他们？这是一个问题。我们倾向于后者，即先实施让人们看到效果。理由很简单，因为人与人之间的知识和经历的差异很大，要全部说服的时间成本太高，甚至于不可能，如果面对是一个有一定经验的人，要想说服他抛弃原先的经验来接受一个新事物，难度恐怕会更高。所以，“暗渡陈仓”或“偷梁换柱”地实施敏捷，是一种切实存在的需求。如果要给这种方法安装一个冠冕堂皇的名字，那就是“传统的项目管理方法到敏捷管理方法之间转换与过渡”。

之所以我们要探讨这种情况，因为我们坚信“敏捷不会把事情变得更糟”，既然敏捷肯定不会“砸场子”，肯定“效果>=现状”，所以“暗渡陈仓”就是有价值的，也是可行的一种推广方法。

我们的目标项目组情况是这样的：团队成员之间技术水平差异较大，但是工作热情高涨，气氛较好，而且项目组感觉“陷入泥潭”已经很久了，看着一堆难以维护的代码，大家都有一种想要改进和突破的渴望。但是团队的关键领导之一对敏捷的态度比较暧昧，不支持也不反对，但对敏捷始终保持着足够的距离，既不拒绝，也不欢迎，更不去深入了解。在管理方法上，项目组采用月计划和周计划相结合的管理方法，即每月定一个计划，本周的计划细化到可执行。但是可想而知，管理比较混乱，计划也经常不准确。

面对这样的项目现状，我们首先讨论的是实施策略：

1. 绝口不谈敏捷两个字，也不谈敏捷相关的什么术语，避免反弹。
2. 选取敏捷方法中最有价值的几个行为，改良项目组的管理现状。
3. 在达到效果，取得大家的认同之后，全面实施敏捷方法。

经过讨论，我们总结出的敏捷成功的要素有如下几个：

1. 管理上的PDCA循环。通过Plan-Do-Check-Adjust形成一个不断改进的循环。
2. 工作的可视化。通过将工作以可视的形式展示出来，让团队对进度有切身的感受。
3. 任务的定量化。所有的任务在阶段开始前就已经定好，一般不再改变。
4. 沟通。定期、按需沟通，保持信息流转的顺畅。信息包括：任务，进度，问题等。
5. 团队工作。团队的每个人都知道所有的事情，了解一致，当然就没有歧义。
 
事实上，敏捷的这几个要素纳入到任何一种管理方法中，这种方法也就立刻符合了“敏捷”的规范，因为“敏捷”本身就是一种“价值观”，在同一个价值观下，可以有N中不同的方法。“老酒”兑“新水”自然也是可以的。

讨论之后的具体实施方法如下：

1. 沿用原来的“月度计划”和“周计划”结合的管理方式。 用敏捷术语就是一个“迭代”长度为1月， 但是考虑到一个月时间太长， 不容易出效果， 所以在每个月的15日加入一个局部总结会议。 实际上把一个月分为上下两个半月，即2周一个迭代。这个也是目前公司敏捷经验中推荐的初期迭代长度。

   a) 每月月初开“每月例会”，内容就是规划本月的工作， 并且将工作细分为可分配的任务， 颗粒度粗一点没关系， 但是要保证一个月够用， 不需要中途再加。 例会上所有的工作都要进行讨论， 保证大家都对工作没有分歧， 其次要对每个工作进行评估，评估的单位采用传统的“工作日”。 只有所有工作都进行了评估， 才能评估任务的进度。

   b) 每月15日左右开“月中总结会”，负责总结一下上半月的工作情况， 讨论改进措施， 并根据进度，酌情调整下半月的任务进度安排。

   c) 每月月末召开“月度总结会”， 负责总结整月的工作情况，并讨论改进。 月末总结会议一般不要和月初的例会合在一起开。

2. 开始实行每日例会。会议上监控如下的几个问题：

   a) 每个人当天的工作状况是否都已经更新

   b) 对停滞超过2天的工作要询问原因，可考虑进一步细化和分解。

   c) 鼓励在例会上交流，慢慢形成交流的气氛。

3. 所有的工作和进度，在白板或者wiki上展示，统一管理。

   a) 初期的工作任务描述可以简单，但是要在计划和总结会议上形成口头共识，防止歧义。 在实施过程中逐步精细化，慢慢达到敏捷对Backlog的要求。

   b) 暂时不考虑使用敏捷工具，避免反弹。

 
在实施过程中，还有一些技巧需要酌情使用：

1. 任务评估由具体执行人给出评估时间，然后乘以相应的系数，作为实际的任务期限。

2. 某些需要形成共识的地方，可以故意引导对方出错，然后给出相应的正确方法。 比如代码难看难维护， 可以先采用“每周代码show”的方式， 逐渐形成集体对代码质量的重视， 达成共识之后，进而引入“代码评审”的方法。
 
接下来的沙龙时间里，我们会持续跟踪这个方法的实施效果。
 
考虑到目标项目是真实的项目，为了保证实施的隐蔽性，本次沙龙会议纪要仅在沙龙成员和特邀嘉宾内部发布，请勿外传！

 

项目管理沙龙第十一次聚会纪要

本来这次聚会要讲一下项目管理的流程概貌，同时对第一个阶段进行一次试探性的深入探讨。可惜这次缺席人数太多，变成了“锵锵三人行”，原定想要谈的内容，也就弱化了。其实每周一次的沙龙，并不需要太多的负担，就当是每周一次的茶会吧，大家紧张了一整周，放松个90分钟，也是应该的。

不过“三人行必有我师焉”，只要有意愿，肯定能够谈出新话题来。

今天分享的知识是“Dreyfus模型”，全称是“Dreyfus技能获取模型(Dreyfus Model of Skills Acquisition)”，是两兄弟研究人工智能时候得到的成果。这个模型把人对知识的学习过程分为几个阶段：新手(Novice)、高级初学者(Advanced Beginner)、胜任(Competent)、精通(Proficient)、专家(Expert)、大师(Master)。这六个学习过程中，新手到胜任的过程基本是线性的过程，但是之后的过程就是非线性的了，每一个过程的进阶都是一个质的飞跃。这个也就能解释为什么小孩子通过“幼小初高中大学”的学习就可以学到和大人差不多的知识。

Dreyfus的六个阶段的主要特点如下：
1.新手（Novice）： 需要详细的指导，要手把手地教，并且新手分不清重点。
2.高级初学者（Advanced Beginner）： 熟悉基本步骤，能够单独完成任务，且觉得自己学得不少了。简历上的“精通”就是从这个阶段开始出现的。但是一旦任务遇到难点，他们就搞不定了。
3.在胜任（competent）： 他们可以分解目标和组合一系列任务以达成某个目标，但是通常这些组合不是最佳的。他们也能初步做一些指导工作，并很讨厌被人指手画脚地指挥。大部分人都处在这个阶段，他们大多不想再投入精力改进，而只想完成工作而已。
4.在精通（Proficient）： 能够给出成型的并覆盖主要细节的解决方案。已经能够将知识和经验结合，开始喜欢谈“哲学”和“方法论”。并且在继续学习中领悟更多。
5.专家(Expert) ：有自己解决问题的方法论。依靠直觉和自发工作，在他自己的领域中很少犯错误。喜欢和其他专家交流来提高自己的能力，更加谦虚和低调。
有趣的是，处于初级阶段的人们倾向于过高估计自己的能力，而在较高阶段的人则更加谦逊。

模型特别指出，大部分人都很难超越“胜任”这个级别。由此可见，那些满天飞的简历里边的“精通”两字是多么幼稚和可笑。

我们的话题谈到了一个没有共识的团队如何逐渐推行敏捷方法的问题。这个是非常普遍的需求，如果需要用另一种方式来描述这个问题的话，就是“如何让敏捷快速见效”？初步的意见就是一些常用的敏捷实践需要立刻实施，因为他们能够解决实际的问题。
1. 最容易开始的就是“每日例会”，它可以即刻解决项目组沟通不畅的问题，让项目经理不再需要询问任务的进度，团队其他成员也不再需要每天填写工作日志。
2. 其次就是backlog的编写和评估，初期可以让项目组自由评估，等到出现问题之后，逐渐改进到用point评估和计算投入时间。

不过这个话题没有深入，但是我们约定下一个聚会就将此作为讨论话题，并且为某个项目组量身定做一个实施计划。

目前到了年底，项目组要么很忙，要么很闲。忙还好办，但是闲就不好办了，所以这个时候需要项目经理更多地去安排一些轻松的任务，最常见的就是安排一些共同学习。而且架构师要去深入地思考一下架构的问题。对于定制交付类型的项目，架构问题还不是很突出，而且很多都已经有了成熟的架构方案，借鉴一下就可以。但是对于产品型的项目，架构就很重要了，而且基本是从无到有的搭建，所以设计就非常重要。就拿EAS来说，简单的CRUD操作定制起来会爽的不得了，但是一旦有了特别的定制，结果就会很难受，有人举例说客户拍着桌子骂人：“你们修改一个标题要10天吗？”

一个不当的设计，很快就会成为生产力的阻碍。很多老板重商务轻产品，无可厚非，毕竟商务会带来现金流，可是有没有人想过，一个没落的产品能够带来什么？有人说一个好的产品能够创造一个新的市场，真的是这样，比如第一个做MQ产品的，第一个做ESB产品的，第一个做数据库产品的，无一例外都生成了一个新市场新领域。

因为话题比较自由，我们谈到了年龄和时间。有人谈到了他一贯的观点：女朋友的年龄=自己的年龄/2+7，然后如果交往顺利的话，就在第18个月的时候结婚，因为这个时候互相的了解已经足够，并且新鲜感没有褪去，一旦时间过长，互相依赖成了一种习惯之后，比如那些在一起5、6年的情侣，越往后结婚的概率越低。从项目管理的角度去看，不仅浪费时间，而且明显风险过大。

浪费时间是可耻的！
（部分关于人生、时间点的内容不想写了）

参考文献：
1. 更好的最佳实践 http://www.infoq.com/cn/articles/better-best-practices
2. 如何从小工到专家——Dreyfus模型应用 http://gurudk.iteye.com/blog/324204
3. Dreyfus模型和最佳实践 http://blog.sina.com.cn/s/blog_493a84550100c8vz.html

项目管理沙龙第十次聚会纪要

会议一开始，就有人跟我们分享了一个名词，“分析瘫痪”，意思是不断地追求完美，结果始终在设计状态，无法到下一步去。详细可参考这个 http://hi.baidu.com/parad1se/blog/item/8724472a71b87e25d52af1a3.html 和 google。与会者都有同感。而破解“分析瘫痪”的诀窍，就是“敢于行动”，因为人就是在不断的错误中学习并改进的，不犯错，当然也就谈不上改进了。如果用沙龙常用的术语说，那就是“敏捷”。

今天的敏捷话题是分享AOM的敏捷过程。AOM是一个基础平台产品，在实施敏捷之前，采用周计划的模式来管理，即每周定制计划，组员按照计划完成工作，并且更新自己的工作状态。这种管理模式在需求控制，角色分工，任务分配和团队激励上，都存在较大的问题，所以AOM团队想到了利用敏捷方法来改进项目管理。所以这一点上AOM和NSEC最大的不同，就是AOM是主动“拥抱敏捷”，而NSEC是“被敏捷”。

AOM有产品经理（PO）的角色，负责需求的最终拍板。敏捷教练（SM）负责团队敏捷过程的正确性和改进，但是和一般SCRUM规则不同的是，SM是项目组之外的人，且不负责项目的进度，项目的进度由项目组自己来管理。项目组依然有项目经理（PM）的角色，但是在实行过程中，这个角色的作用被弱化了，变成了一些关键事务的协调人和PO的代理人。日常的进度监控工作，则由轮换的“主持人”完成。

在产品的计划会议上，AOM使用纸牌游戏的方式来对每一个任务评估point数。并且根据团队的能力，设置sprint计划的point总数。和NSEC不同，AOM不会在每一个sprint中预留point，而是将一些项目之外的事务变成backlog放到sprint中一起进行跟踪。如果外部干扰太大，就要及时调整sprint中未开始的backlog，删掉一些优先级较低的backlog，并且用更小的backlog弥补进来，并保持sprint总的point数不变。就像长跑的时候呼吸和脚步的频率要非常一致才能跑得很好一样，敏捷过程也很重视“节奏”。所以AOM的sprint时间长度也基本是稳定的，目前是两周一个sprint，部分为三周。

在产品的回顾会议上，所有的问题都会被分析一遍，对于投票最多的前三项问题，会在下一个sprint中生成backlog并分配专人跟踪和完成。其他问题，如果是规则性的，就会去更新规则。

每日站立会议上，主持人会先向大家通报一下上一个工作日的task完成情况和进度的预测，然后团队每个人再回答一下三个问题：昨天做了什么，今天做了什么，遇到什么困难。在日常任务的跟踪上，AOM通过纸质的任务看板和纸质的backlog卡来进行跟踪，每天下班前，主持人会根据看板的进度情况，敦促当事人及时更新任务卡片，并将任务卡片的进度数据同步到ScrumWorks中（大家回忆起了读书时候的“课代表”）。每次站立会议都会有一个人记录会议纪要，并且将其内容登记在wiki上，以便全体成员（包括缺席人员）备查。

主持人机制在AOM敏捷过程中占据十分重要的地位，它负责对团队每个成员进行敏捷管理意识和能力的培养，通过角色轮换的方式，让团队成员获得一种比本职角色更高的角度去看待软件开发和管理，尝试他们以前不太有机会去尝试的团队管理或设计方面的工作。在AOM团队中，主持人按周轮换，除了跟进项目进度之外，还要负责控制会议的时间。

不同的会议，控制时间的基准也是不一样的。对于计划会议，则每个backlog的讨论时间=会议计划长度/sprint中backlog数目。对于每日例会，每个人发言时间=15分钟/发言人数，最长没人发言时间不超过（30分钟/发言人数）。回顾会议上，每个问题的讨论时间=会议计划长度/问题总数。另外，对于讨论和辩论，控制时间是每项讨论和辩论不超过1分钟。只要超过时间，主持人就会主动打断，维持会议效率。

AOM同时也引入了“结对”的机制。组员自由结对，分主副手。所有的任务要两个人同时签名才有效，主程序员负责编码，副手负责单元测试，并且在sprint结束之后，主副手角色调换，副手负责维护该部分代码，包括修改bug和增强功能。这种结对延伸到项目组的每一个方面，所以每天站立会议会议纪要，也是会议主持人的结对伙伴来记录的。

AOM的敏捷过程中，大家发现使用纸牌、看板、任务卡片的方式，使整个过程充满了“游戏性”，具有很强的“参与感”。组员之间互相关心，在任务分配上更公平，工作效率更高，每项任务中的职责分工更明确，当然产品的质量也更高了。而且轮换主持机制让每个人都有更多的角色体验，可以让PM空出来思考更深层的问题。

目前AOM尚未在每个sprint结束之前进行show case。

与会者在讲述过程中插入了很多的讨论和分析，大致有如下几个话题：

与会者首先关心的是“需求来源”问题。因为项目的特殊性，AOM的需求更多来自于团队的拍脑袋，其次是公司内其他项目提出的要求。与会者一致认为，不管怎样，“有目的的手机用户需求”是肯定的，但是需求的筛选也是值得注意的方面，要结合项目的目标来进行。比如iPhone多半可以肯定不会去实现什么“双卡双待”和“收音机”的功能。但是有时候的“拍脑袋”和“摸着石头过河”也是不可避免的。这就要求PO充分担负起责任来，PM也要担当一下，比如某些需要预研才能确定做不做的技术，就要先动起来。

关于showcase，有人发现公司的一个怪现象：“产品的名字大家都听过，但是长相大多都不知道”。仅从这个意义上去看，showcase的重要性也是不言而喻的。大家一致的意思是要用起来，因为它可以让团队充分感受到目标和时间的压力。但是初期不一定非要每个sprint都show，在掌握方法之后慢慢提高，最终达到每个sprint都show的程度。但是一定要注意showcase是要求不要做特别的准备的，也就意味着showcase的成果就是日常工作成果。

“到底有多敏捷”是与会者提出的一个问题，有人觉得公司内部的过程改进组织就应该来回答这种问题，通过对项目组敏捷过程的观察，给出一个敏捷的级别，并且以此来逐步指导和提高项目组的敏捷程度。

有人关心“任务没有人领”的问题，经过讨论，我们发现虽然有部分任务会存在只有某人能够完成的情况，但是只要经过细分，大部分任务的难度都会降下来，并降到其他人也可以认领的程度。有人发现如果能够将“个人学习计划和任务结合起来”，是可以降低某些任务对人的依赖性的。

“如果团队中有破坏者怎么办”，这是有人用“六顶思考帽”的思考方式提出的问题。但是大家在讨论中发现，利用每日例会和看板，我们很容易发现那些虚假的进度汇报，并且敏捷中持续的沟通，让谎言在其中生存的难度变得极大。一旦“破坏者”被发现，要么被清除出团队，要么自动离开，或者痛改前非，融入团队。

在分析“轮换支持”机制的时候，有人举例了IBM的60%工作，40%沟通的时间安排比例，谈到了如何让员工更多思考，聪明工作的问题。不过未展开。

敏捷其实不是一种新生的事务，无论从其指导思想，还是各种使用的工具和方法，大部分都是敏捷提出之前就已经存在的，比如看板就是源自丰田的精益管理方法，每日例会则来自于服务行业。现在敏捷已经不仅限于软件开发，在市场销售、公司管理都有应用案例。

最后，有人提出“敏捷管理方法如何在餐厅运用”的问题，引起了大家热烈的讨论，但是考虑到沙龙的时间，讨论在一片欢乐中结束，不过我们不排除以后会抽出一个专题来讨论这个问题。

项目管理沙龙第九次聚会纪要

前不久在腾讯举行了2011敏捷大会，但是因为加班或者报名的原因，沙龙里只有一个人参加了敏捷大会，所以本次聚会由夏勇分享参加大会的心得。

对大家印象比较深刻的首先是雅各布森给出的一系列敏捷卡片，我们拿到的这一系列卡片有四组，基本覆盖了敏捷过程的方方面面，对于敏捷过程的指导作用还是比较强的。所以我们决定接下来将这个卡片电子化一下，让每个人都可以看到。

QZone的产品经理的演讲还是挺让人感兴趣的，他号称是QZone每周五天可做到约二十次发布。在这种情况下，如何保证项目成果的质量稳定，是需要一定的水平的。QZone前台使用php，后台使用C++，所有模块集中发布。他们有一个专门的发布系统，可以做到“一键式发布”。他们在发布之前做的测试，只测试一些关键逻辑，小的地方就不测试了。QZone自己把这种发布形式叫做“灰度发布”。结合从会议上听到的消息，我们分析他的测试方法大致有如下几个：产品关键部分要做专门的测试；修改所牵涉的部分做简单的测试；使用招募的内测用户对系统进行在线测试；将用户群拆分，比如把某个二线城市的用户都切换到新版去用，跟踪他们的使用状态等。有人举了一个淘宝为世纪光棍节做系统压力测试的例子，因为要产生一个访问的峰值，所以淘宝发了一个优惠券让大家去抢，结果峰值自然就出来了。不过像QZone这样的测试，最小测试颗粒度都应该是User Story级别的，再小可能就太细太多了。

QZone在划分Backlog的时候，先定2～3个月的目标，颗粒比较粗，然后定每个sprint的目标。我认为这种形式比较适合于那些开始时候需求不明确，需要在过程中不断挖掘需求的项目。在制定Backlog的时候，采用颜色将Backlog分类，比如数据界面的Backlog标为绿色，属于Bug的标志为红色等。这个办法值得学习。

敏捷会议上的另外有人提出了“轻敏捷”的概念，和与之相对应的“传统敏捷”相比，他抛弃了过程数据的收集，只看结果。其他经验的包括流程可视化，流程梳理，以及交流一定要面对面。

雅各布森讲了“如何做有效的Backlog”。大致就是说从项目干系人、蓝图、用户的变更申请等处得到Idea，然后把Idea整理成Use Case。Use Case要包含范围、场景描述等。再基于Use Case整理出可以Telling的Story。最后把Story拆分成一个个可以交付的Backlog。经过优先级排序、价值评估、风险评估之后，就可以将这些Backlog纳入到Sprint中去。

一个Backlog可以分成许多个Task，一个Task分配到一个人。在状态处理上，Task可以被Block，Backlog可以被归为impediment。Task的颗粒度要细分到保证能够在一天内完成。一个Backlog的所有的Task完成之后，称为Backlog的Complete，但是Backlog要从Complete到Done，还需要经过测试和验证才行。所以要注意所有Task完成之后，到Backlog的Done还是需要有时间的。另外，上一次Sprint没有完成的Task，要作为下一个Sprint中最高优先级的工作来做。

下一次聚会，我们请AOM讲一下他们的敏捷实战经验。

项目管理沙龙第八次聚会纪要

本次沙龙依然是NSEC的敏捷经验总结。这次依然谈到了客户与需求的问题。因为客户和开发组不在同一个地区，所以客户完全没有参与到项目的开发工作，所有的沟通都通过项目经理来进行。从开发人员的角度看，需求变化最大的问题是开发人员无法确定是否真的是对客户有用的。客户首先是自己有很多的想法，变来变去，PM也因为距离的关系，无法和客户面对面沟通，所以也就只能拍脑袋和猜谜语。结果开发人员心里没底，做不出成就感，心情自然也就好不起来。引出的问题就是：开发人员到底怎么办？

面对这种情况，经过讨论，大家认为首先还是要充分信任PM，但是PM也有责任去和客户充分沟通。这个时候，我们一直强调的“原型法”就会有很大的作用。原型工具可以有很多种，比如一连串简单的html页面，或者一个ppt演示。前者的好处是可以快速地完整演示一个流程，后者的好处是可以将一些用户界面效果也同时演示出来。总之，原型工具就是那种可以快速构建，快速抛弃的东西。非常适合用在客户需求不稳定甚至不成形的情况下。

实际上，NSEC的需求问题根源并不在客户，也不在PM，而是和其他大多数项目一样，缺少了一个角色，“业务分析师”，简称BA。许多项目的BA都由PM担任，或者商务人员担任，但是他们要么身兼多职，要么没有受过专门的业务分析训练，无法充分引导客户的需求，结果就造成了需求不明确，不稳定等问题。引用沙龙成员的一句话：程序员不反对变更，但是反对浪费！

BA的作用很重要，在敏捷结对中，BA的结对对象就是客户代表。他的工作就是负责引导客户，让他们的需求变得更明确，更稳定。原型法是一种很好的需求引导方法，就像我们一直强调的，“客户不知道自己要什么，但是明确知道自己不要什么”，原型法的作用就是让客户能够不断地否定自己的想法，最终形成一个明确稳定的客户想要的东西。这个也就是项目组梦寐以求的“稳定的”需求。其实BA的工具远远不止这些，“语法分析”也是BA的工作利器。根据客户所说的语句，将其划分为名词、动词、形容词和主语、谓语、宾语。根据每一个词语的特性，我们可以整理出一系列有针对的问题。一个有经验的BA，只要客户不断地开口说话，就会将客户的所有需求都问出来。具体的方法，我们可以在以后的沙龙中详细探讨。

NSEC的另外一个问题是客户不定期不定时地要求项目组发布成果。针对这种情况，我们觉得自动化构建和上次谈到的UAT环境就很有作用了。这种问题的出现，根源其实还是在客户需求的不稳定上。当然，定期发布成果并让客户能够感受到进度的变化，也是非常重要的。

“没有验收标准文档”是另外一个NSEC的问题。从我们的角度看，这个是中国几乎所有项目的共同问题。理论上，我们会在中标之后对客户进行需求调研，然后把形成的需求规格说明书作为合同的附件，并以此作为客户验收的标准。实际上能够做到这种程度的项目几乎没有，即使做到了，这个合同附件中的需求也会在开发过程中不断地变更，最终变得面目全非。有经验的人肯定会拿出“变更控制”的办法来，可是实际项目过程中，有多少客户愿意每次需求变更都来签字呢？又有多少客户代表因为要签字就放弃需求变更呢？答案都是“很少”甚至“没有”。很多项目就是因为限制客户变更需求，或者变更需求过程中和客户经常产生不愉快，导致客户关系恶化，最终项目失败。这个也是“传统”项目和“敏捷”项目的最大的区别。

从敏捷的角度去看，项目组完全接受变更所带来的影响，但是所有的变更都不能影响当前正在进行的迭代过程，所有的变更最快也要到下一个迭代才能生效。但是真的有紧急的需求变更怎么办？事实上并不存在什么“紧急”的需求变更，因为所有的需求的实现都是需要有时间的，需求是一种未来性质的东西，项目组一定要把“需求”和“BUG”区分清楚，不能用解决BUG的方法去应对“需求变更”（这个也是大多数项目组常犯的错误，任务没有优先级的结果就是经常性的加班）。针对一个需求变更，除非它能够让当前迭代的某个任务即刻作废，我们才需要即时改变迭代的任务安排，否则本次迭代不受影响。

没有验收标准文档是一个问题，但是“依赖客户进行测试”是另外一个更严重的问题。因为之前所讲的客户不定期要求项目发布，所以项目组在发布的时候的时间都很紧张，加上平时没有充分的测试，所以项目组就希望客户能够抽出人力去做验收测试。实际上，客户几乎不会去做什么认真的测试。有与会成员认为“依赖客户进行测试”本身就是项目的一种失败。