接上一篇。。。。。。
段誉：“XP之所以认为保持一个平稳开发速度是非常重要的，和另外一个实践迭代发布有着重要的关系，接下来我就讲一下迭代发布的实践。迭代发布，这对我们来讲都是耳熟能详的了，无论是在非敏捷的开发过程RUP统一过程也好，在各种敏捷过程也好，如FDD功能驱动开发、SCRUM开发过程，它们毫无例外都是强调迭代开发的，迭代开发已经成为当今软件开发组织必备的工具，XP的迭代发布来源于反馈的价值观，要不断的获得客户的反馈，那么就必定需要不断的版本迭代，这是很简单的道理。那么XP的迭代发布与其它方法学的迭代开发有什么不同呢？XP的迭代发布也是体现在极限两个字上，在其它的方法学里面通常对每个版本的迭代时间要求在一个月以上，甚至是几个月，很少会要求少于一个月，但XP不是这样，它对迭代时间的要求与其它方法学大不相同，通常它认为迭代最好是一到两周，最多不超过一个月，每次迭代产生一个小版本，每三个月进行一次大版本的发布，它认为这样做能够增加客户反馈的频率，能够更好的应对需求的变更。”
虚竹：“为什么这样做能够更好面对需求的变更？”
段誉：“因为XP是强调拥抱变化的，即使在项目的后期也随时欢迎需求的变更，为了应对需求的频繁变更，XP想出了这么一个办法，就是以小步快跑的方式开发项目，每个小版本在一到两周之内完成，然后提交给客户，在每次开发的这一、两周内让程序员专心开发，客户不能提出需求的变更，以免影响了进度，但一旦提交了每个小版本以后，客户则可以随时提出各种需求的变更，也就是说可能客户每隔两周就能够对需求做出一次变更，并且在接下来的迭代周期中完成变更。”
虚竹：“在这里我提出三个疑问，第一，以我们公司的实际情况，每一、两周提交一个小版本给客户试用，让客户提出反馈，这是不太现实的，因为我们没有现场客户，非现场客户肯定是很难做到这一点的；第二，即使勉强能做到这一点，每一、两周让客户提供反馈，但如此一来，必定会让项目过早的陷入了维护模式，一方面要开发新的功能，另一方面还要根据客户的反馈修改之前的代码，这对项目的进度影响是很大的，尤其重要的是，前面我们已经讨论过，中国的客户大部分是要求软件公司在某一个时间点必须完成项目开发，而不管需求如何变更，因此无奈之下我们必须去控制需求，在这种情况为了公司的生存，为了能够按照合同按时完成项目，我们也不希望迭代的周期太短，因为根据我的经验，周期越短，客户提出的需求变更就会越多，我们就越难按时完成项目；第三，过短周期的发布会让团队成员过于紧张，压力过大。”
段誉：“这就是前面我说的XP现场客户的缺失会极大影响它的另一个实践迭代发布的效果了。”
乔峰：“无论如何，XP迭代发布的概念是值得我们去学习的，它的确能在一定程度上去应对需求的频繁变化，但也正如虚竹所说，迭代周期过短也有它固有的缺点，至少在我们公司是不现实的，因此我建议把每次小版本的迭代周期定为一个月或者一个半月就相对比较合适了，这样每次迭代的时间不太长也不太短，它共有三方面的好处：第一，能够保持一定的反馈频率，适应需求的变更，让客户获益；第二，能够让项目成员时刻拥有一点压力有助于维持一种较为高效的开发效率，符合精益化的管理思想；第三，同时也不会让大家精神过于紧张，并且能够让团队始终集中精力在交付上。”
段誉：“您说的是，如此看来，每一个或一个半月一次小版本的迭代，能够提供更多的反馈，作为应对需求变更的手段，能够作为项目进度的里程碑，每三个月发布一个较大的版本，能够提供给客户一个有价值的、可以运行的系统，这是目前我们不错的选择。另外有一点我还想说一说，前面已经说过XP迭代发布的实践和可持续速度的实践是紧密相关的，那是因为如果无法保持项目成员拥有持续的、旺盛的精力，就无法保证每次迭代的顺利完成，从而最终也谈不上每三个月发布一个版本了。”
虚竹：“看来XP的每个实践真的是紧密相关的啊，缺一不可，我们在剪裁XP的过程中真的是要小心谨慎，否则恐怕会弄巧成拙。”
段誉：“事实确实是这样。接下来我讲一下XP的另一个实践用户故事，用户故事来源于沟通和简单的价值观，也就是说XP通过一个个描述简洁的用户故事来进行需求的沟通。”
虚竹：“用户故事，这个名字可真奇特。”
段誉：“这个名字是从英文翻译过来的，也可以翻译为用户描述。前面已经提过，由于有现场客户的存在，XP认为详细的需求文档是不必要的，因为详细的需求文档是不敏捷的，那么XP的需求主要是通过什么来表达的呢？答案就是用户故事。XP通常会在每次迭代开始之前召集团队成员包括现场客户开一个会议，在会议上由现场客户提出需求，然后把每个具有一定价值的需求点记录在一张张的小卡片上，每张小卡片就是一个用户故事，里面简要的记述了用户提出的需求，会后再由现场客户根据各个用户故事编写一份验收测试清单，清单里面描述了每个用户故事的编码实现应该如何才算通过了测试，达到客户的要求，当然验收测试的写法会有一定的技巧，这需要团队成员对现场客户给予支持。最终开发人员根据用户故事卡片和验收测试清单开发系统，并且现场客户随时接受开发人员的咨询，解释系统的需求，从而相比传统方式达到一个更为敏捷的过程。XP这种获取需求的方式与《领域驱动设计——软件核心复杂性应对之道》一书中讲到的方式略有不同，领域驱动设计更强调的是客户与开发团队共同维护一套所构建系统的领域模型，而不是简单的用户故事小卡片。”
虚竹：“XP在这个实践上的敏捷性是建立在拥有现场客户团队之上的，现场客户团队代替了大部分需求文档的功能，但由于我们的项目很难拥有现场客户，更不要说现场客户团队了，因此我觉得我们的开发过程在每次为期一个或一个半月的开发迭代前还是需要编写详细的需求分析文档，并且在开发之前让客户签名确认。当然，我们也可以引入《领域驱动设计》作者的思路，与客户共同维护一套领域模型从而形成整个项目团队通用的语言，以尽量减少客户与开发团队之间在业务理解上的鸿沟。”
段誉：“我赞同你的观点。接下来我再讲讲XP的下一个实践，它与用户故事的实践是紧密相关的，那就是计划游戏。”
乔峰：“计划游戏，呵呵，很有趣的名字。”
段誉：“计划游戏主要来源于反馈的价值观，在每次迭代的开始时期形成用户故事以后，首先由现场客户根据优先级来选定本次迭代所要完成的故事，接下来项目经理会和团队成员一起把每一个用户故事分解成多个任务，并由各团队成员估算每一个任务的完成时间，大家签单领取自己在本次迭代中所要完成的任务。我们大家都很清楚，在系统开发过程中要想精确估算每个任务的完成时间是比较困难的，XP通过两个办法来解决这个问题，第一，在把每一个用户故事分解成任务的时候分解得足够细，细到能够更好的评估开发的时间；第二，尽管一开始估计的时间偏差会比较大，但每次任务完成后都会有专人记录任务估算的偏差度，并提供反馈，因此随着不断的反馈，每个团队成员估算任务的偏差会越来越小，直到达到一个较为满意的程度。”
虚竹：“计划游戏是一个不错的实践，上面已经讲过，由于我们没有现场客户，因而我们也就没有用户故事，我们拥有的是详细的需求文档，拥有的是用例，因此我们可以尝试在以月为周期的每次迭代开始之前，让客户根据用例的优先级选定本次迭代的用例，然后再把用例分解成多个任务来达到XP类似的效果。不过有一点我想重点提一提，那就是目前按照我们公司各项目组的实际情况，每个项目经理在估算任务开发时间的时候都没有让开发人员参与，仅仅根据项目截至时间来反推任务分配时间，这是一种错误的做法，它会导致分配的任务完成时间在很多时候根本不具有实际的意义，久而久之会导致很多不良的后果。”
未完待续。。。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
