XP迭代的计划和运作

XP迭代的计划和运作

LinuxAid.com.cn axing 2001-12-17

    在步入新千年的时候，我们迎来了一个有趣的XP项目。说它有趣，不仅仅是因为它是我们在ThoughtWorks的第一个XP项目，还因为它的庞大：大约有50人。在这里我们将讨论我们如何为每一次单独的迭代建立“必要活动计划表”，如何仅仅围绕它开展项目，以及各个子团队如何围绕着迭代工作。

简介

    ThoughtWorks公司位于芝加哥，是一个系统集成和顾问公司，拥有300名员工。我们擅长利用工业中的新的、具有战略性的技术开发有较高难度的商业应用。我们也做复杂商业应用。这通常需要整合各种组件，扩大组件应用和改变商业逻辑。我们在出租业方面做了大量的工作。这个行业通常不会有那些简单、清楚的合约。如果你看过一份租用协议，你就会明白我的意思了。
我们已经在建立要求苛刻的租用系统方面花了很长的一段时间了。我们采用EJB来构建系统。这是个非常大的系统，那些卖主们已经花了十年的时间来建立他们的系统。在我们彻底改进我们的方法之前，我们花了18个月的时间来收集需求，创建原型，以及着手开发。我们遇到了很多的问题，这种项目所特有的问题。需求很难理解，不停的变化。控制这么一个庞大的项目对开发方和客户关系来说简直就是严苛的考验。在这时，我们开始接触Extreme Programming（XP）的一些思想。我们感觉到它正好适合我们这个项目的特性。同时，XP也很适合我们公司的文化。所以8个月前，我们就开始以XP的方式工作。

    不过，适合归适合，却没必完美。XP是为那些不超过20人的团队设计的。我们的团队却有整整50人，其中一半是开发人员。XP鼓励频繁的发布产品版本，而我们面对的是要建立一个新系统来替代原先的复杂系统，这就意味着我们在发布用户能够真正使用的东东之前必须要经历老长的一段时间。所以我们一开始就知道有这些因素在，我们就不可能按书照学XP的做法。（不过我们也没有按书照做，虽然那本书是我们写的！）所以我们的流程中很重要的一个部分就是每个月对流程进行一定改进，并在全团队中分享经验，重新设计我们的XP方法以适应我们的需要。

    当我们开始XP的时候，我们先制订了一个计划，包括了18个月的素材卡片（大致上相当于功能），以及把这些素材分成多次迭代。XP运作项目的方法是将项目分成多次的迭代，每一次的迭代交付一个通过质量检验、可投入使用、包含了一些新实现的素材卡片的软件。我们每次迭代的时间花差不多一个月。（比XP建议的稍长一些。）这样每个月顾客都可以看到系统都会增加一些新的功能。

    这篇文章就是讨论我们现在怎么做这个项目的。我们打算周期性的改造我们的流程，而且会腾出手来更新这篇文章。我们还会讨论我们作出的一些改变以及我们为什么要改变它们。

团队结构

    我们的团队有50个人。项目的管理办公室包括了两个发布经理，他们主要负责和客户及发起人的会面和沟通。日常的计划工作由版本经理和迭代经理负责。版本经理负责较长时间的产品发布计划，这通常是不稳定的，时间跨度从六个月到一年。迭代经理则专注于迭代计划――每次单个迭代的具体细节部分。
版本经理和迭代经理的区分体现了两个不同的人做事的风格。原来他们只是交替的担任每次迭代的迭代经理。但是我们发现Matt比较适合跟踪正在进行的迭代，而Cara更善于长远版本计划的制定。所以他们就调整了相互的角色以适应他们的能力和兴趣。当然，我们的项目采用这种方法并不意味着大家都要人云亦云。XP的一个重要部分就是所有人都必须对他参与的工作感兴趣，这一点也同样适用于管理者。

    在这个XP团队中，我们的客户团队有12个人。包括了我们内部的领域专家和将会使用软件Beta发布版本的客户。

    团队中的开发人员大约是25人，分为两个小组。领域小组独自负责编码实现每次迭代中新的功能。SWAT小组负责修正bugs，建立流程，测试自动化以及那些和新的功能没有太大关系的事务。我们之所以这样划分团队，是因为我们希望设计能够一气呵成，避免人们因为相互交错而导致的进度缓慢。有13个人来负责在给定的时间中给代码库增加新的功能是足够的。我们在每次迭代中，一部分的开发人员会轮流在两个小组间工作，这样，每一个开发人员都隶属于过这两个小组。

    我们的品保人员是8个人的团队，负责每日的回归测试。决定每次的迭代结束时应该交付哪些素材卡片，准备每次交付的版本记录。

    从领域开发者的视角来看，迭代过程非常的简单。每一次迭代开始时确定一批新要实现的素材，交给品保人员，然后开始下一次的迭代。然而围绕着这简单的素材有很多的工作要做。团队的每个部分都有他们自己的工作周期。大多数的团队都要花费差不多一个月的时间来处理资料，这些资料来自于三个给定的迭代周期：当前迭代、前次迭代、下次迭代。

    为了示例我们的XP方法，我们把重点放在一次特定的迭代所必须的工作上。为了简化描述，我们选用数字6来示意迭代。我们所描述的工作其实要比我们真正迭代中要多。（我们可没打算每次在更新文章时候更新所有的迭代。）迭代6原本安排在6月，不过部分的工作会安排在5月和7月。当我们在讨论项目的时候，会把注意力集中在团队正在工作的此次迭代上。于是我们常常说，“在迭代5的第一周，计划者就会准备好迭代6的素材卡片清单。”每个小组都会有自己的周期表，列出了他们在迭代5、6、7中要做的事情。为了清楚的的看出表中的活动流，我们隐藏了迭代6的所有活动，这样你可以清楚的看见在真正的迭代开发的前后，都会有哪些活动。你也可以查看consolidated cycle table 来了解所有小组的活动。

计划周期

    在版本计划尚处于一片薄雾之中的时候，简略的第一版迭代计划就要准备好。版本计划根本不稳定，非常易变，在我们了解客户需要和开发人员的工作的过程中，版本计划在不断的改变。版本计划中包括了迭代6的一系列素材和大堆的功能。虽然版本计划在不断的改变，但并不妨碍它成为一个基本的工具。它给我们指出了一条路，告诉我们要结果怎样，如何改进，和评估事件对我们的影响。

    5月初，在迭代5开始一段时间后，版本经理就开始热切的寻找迭代6的内容。客户小组和迭代经理共同确定哪些素材应该在6月交给开发人员。随着迭代5的开始，我们知道迭代5会实现和不会实现的功能。有了这些信息，你就知道在当前的迭代中，哪些素材不会被实现。除此之外而且你要准备评估下一阶段的工作。现在版本经理就可以收集整理迭代6的所有信息了。

    首先要调整优先级，以确定下一阶段的素材卡片清单。只要开发人员的周计划已被评估，且已经加入到这次迭代的周计划中，客户就可以任意选择素材卡片。这就叫做周转率。在这个案例中，我们安排了28个星期的理想开发时间，这个决定是根据我们在迭代4中所花费的时间得到的。

    客户有权利提出没有排在当前计划中的新功能，把延后的功能排入计划，去掉当前迭代中的安排好的功能，或是重新调整卡片上的优先级。用素材卡片的话来说，客户根据他们目前的商业需求和策略，可以创建新的卡片，把他们加入计划，或是完全移出计划，或是把他们分成多个卡片排出他们的优先级。我们会要求开发人员询问客户，重新评估这次迭代需要考虑的素材。对项目更多的了解和对素材更多的关注有利于精确的评估，这样我们就可以准确的评估下一次的迭代了。

    计划导致版本计划的再次开展。通产需要花费一个星期的时间来讨论下个月的功能性的过程。这个工作一结束，分析周期就开始了。

    在准备迭代6的计划会议的过程中，版本经理必须要确定这个月中的开发人员的开发天数。这意味着，要计算人们的假期和培训时间，本月开发人员的有效时间，将上一次迭代的周转率的时间转化为这一次即将到来的迭代的理想的开发时间。

    迭代6一开始，迭代经理就必须做好迭代的计划工作。在迭代计划会议上，开发人员提出一个迭代计划。迭代经理就会跟踪这个迭代计划，调整附近时间内的一些迭代，以及考虑这次迭代给客户的交付版本。



    迭代6开始前两周，领域专家会开会讨论即将到来的迭代所需的功能。在对新功能应该如何运作的细节有了共同的意见之后，他们会把精确描述功能的责任分割为工作产品，我们称之为叙述。每个素材都有一个本次迭代的叙述。一个叙述类似于一个用例，但没有用例那么正式。我们用比用例中更散文性的语气来精确描述一个新功能。

    在叙述的最后，必须准备好相关的测试场景的草图。至少，测试场景具有充分的关联性，让开发人员能够估计素材卡片相关的具体编程任务。这个测试场景会展开成为最终测试，必须来充分的测试素材卡片的功能。如果时间容许，这些测试场景的扩展工作应该优先于迭代6的计划会议。在实际中，一般最后都会生成测试脚本，贯穿迭代6的整个过程。

    领域专家会议同样应该先于迭代6的计划会议，会议要审查叙述，签署素材卡片。签署素材卡片表示：同意在迭代计划会议中提出该项叙述，做为迭代中开发人员的接触点，保证卡片测试脚本的质量和完整性，在迭代结束的时候把功能提交给QA小组。



迭代计划会议

    迭代计划会议是一个大规模的会议，囊括了全部的团队成员，迭代过程中的需要实现的所有功能。所有的开发人员和分析人员都必须参加。（这时，QA人员正处于他们的周期中的关键时刻，所以只有代表列席。）会议需要一个大的房间，墙上贴着大幅的素材卡片。这里有一些基础规则：使用麦克风，关闭手机，不要带笔记本电脑，也不要有抱怨。

    所有与会者都会得到一份叙述文档、一份范围文档。范围文档把系统分为多个大范围功能性区域，每个区域都指出哪些素材卡片需要实现，这个迭代中要实现的和以后的迭代中要实现的。我们发现这对于分辨这个迭代该做什么和不该做什么的时候特别有用。

    在享用过甜饼和咖啡之后，按照议程，分析员会对在叙述中描述的功能展开讨论。我们讨论场景。分析员阐述功能，而开发人员则会对应到具体的编码。开发人员会对每一张卡片拟出完整的开发人物列表提纲。当提纲做好后，会被记录到一张大的贴纸上，粘到素材卡片上。

    午饭后，我们结束功能讨论，把素材卡分为多个任务。开发人员会分成多个小组评估每项任务。对大多数的项目来说，开发人员在目标卡片上的开发时间往往会超过原先团队估计的时间。所以客户会在开发人员的建议下，提炼出整个的卡片或是部分的任务，放入迭代中。在商讨哪些任务需要放在计划之外的过程中，那些独立的任务或是整个的卡片实际上都已经成熟了。

    虽然这种提炼已经成为项目的日常特色了，不过在最后几次的迭代中通常不会发生这种提炼。这是因为我们的版本计划在不断改进，我们能够相当精确的估计出一个迭代计划会议中需要讨论多少的素材。这里有一点很重要：在讨论迭代计划之前让开发人员先进行较精确的评估。你评估的次数越多，评估的结果就越精确。



    一旦功能选定之后，开发人员需要在任务上签字。这里有几个基本原则：每个开发人员负责的任务应该不要跨越了大量的卡片，一个卡片业不要太多的人来负责实现它的任务。每个卡片都要有一个分析员和一个品保员，他们要在会以前先在卡片上签字。一个开发人员同样要在卡片上签字，那些负责这个卡片下的任务的开发人员也一样。

    这样，会议的结果包括了：一个迭代的功能列表，体现了关联性，分配了职责；一个开发人员自己拟定的充分的开发计划评估列表；给每个素材卡片、每项计划分配了资源。这样，团队中的所有人都参与了这个过程，熟悉了下一个月的迭代中要实现的新功能计划，这些都在墙壁上的招贴上画着呢。
历史经验表明，我们的迭代计划简直是难以置信的精确。很少会发生无法完成那些在迭代计划中签好字的素材卡片的情况，这提高每个参与者的信心。迭代计划可以说是对一个月内的未来的最稳定的预测了。

    在如何把功能展现给开发人员这个问题上我们觉得还有很多的工作要做。一个关键之处是叙述并不是最终结论。在迭代中，开发人员会频繁的和分析人员讨论功能的细节。在迭代计划中，开发人员并不需要所有的信息，但他们需要足够的信息来将素材分为多项任务以形成迭代计划。这个步骤需要一些初始的设计工作。

    可是问题在于分析人员能不能确保把所有重要的事情全部告诉开发人员。可对于开发人员来说，他只需要知道今天的工作所必须的信息就足够了。所以我们的难点就是开发人员希望简洁，可是分析人员更关心能够把那些影响客户期望值的东西略去。

    我们尝试着不需要叙述来做事，或是让版本经理代替分析人员来负责展现叙述。效果都不是很好。我们最后的尝试是开一个预备会议，会上部分的开发人员会检查相关的部分叙述。这可以解决前面提到的一些问题。

领域开发周期

    领域开发人员在每次迭代中负责给基本代码库增加新的功能。在整个迭代周期中，他们将和领域专家以及其它的领域开发人员一起工作。领域专家将和开发人员呆在一起，面对面的解决问题，共同完成在计划会议中签署的任务。开发人员间的合作可以通过好几种途径。每隔一天，程序员都要开一个stand-up的短会（会上所有人都站立，以保证会议尽快结束，故称“stand-up”），讨论他们现在的工作，共同解决开发中的问题。



SWAT开发周期

    SWAT团队将会负责迭代中那些和新增的功能没有太大关系的事务。所以SWAT的工作就是除开发任务以外的其它事务。这样可以保证领域开发人员的全心全意的开发新功能。他们的工作包括，修订上一个版本的bug，自动化测试，理顺构建过程，调整性能，升级等等。

    在迭代结束的时候，SWAT团队将只会修正那些最紧急的bug，保证新版本的交付。一旦迭代结束，功能就一般不会修改了。所以，在编码时实现过多的新功能是非常冒险的。比较好的解决方法是将未完成的功能放到下一个迭代中再来实现并交付给客户。



品保周期

    在迭代周期中，品保人员通产采用执行回归测试的方法来保证上一次迭代交付的产品。在迭代结束的时候，开发人员都匆忙结束那些功能，获得该卡片相应领域专家的许可。而该卡片指派的品保人员就要负责“卡片通行”。这需要品保人员和领域专家、领域开发人员和SWAT团队合作来保证每一项功能和该项功能的测试能够紧密结合，并能够通过有效的测试交付给客户。一旦品保人员允许或拒绝迭代中每张卡片的“卡片通行”，我们就要构建一个最终的发布版本提交给客户。品保人员、项目经理和领域专家会共同撰写版本记录文档随同最终版本发布。这个版本记录给用户大致描述了新的功能以及如何使用。这包括了素材卡片，叙述和测试，迭代过程（当前迭代和整个项目）。品保人员还要负责调整确切的交付日期。作为迭代经理的助手，品保人员同样要负责提供新功能和培训用户。



成功之处

    至此，我们已经发现了一些行之有效的XP方法。

    关于我们在一个给定的迭代中所做的工作的估计一定要非常的精确。一次迭代中我们想要实现的所有卡片在这次迭代中几乎都要能实现。

    迭代中的所有的卡片都要有实质的、可论证的过程。每个月我们都要进行一致的、快速的、可论证的过程。

    无所不在的交流：团队间，团队和客户、发起人间的交流都得到改进。计划会议使所有人都能相互了解。团队、客户和发起人都能够清除的表述迭代目标。

    客户也能够分享这个制造过程。客户能够改变他们的主意，而我们来实现。
由于团队成员和应用都能够落到实处，对于这个项目到底是什么的疑问也不再困惑着项目成员了。

    我们的项目方法自身经历了迭代过程的改进。这种改进是全团队发起的。
当我们第一次接受这个流程的时候，团队的士气空前高涨。并且，士气一旦稳定下来，就不会再下落。

    而我们从这个项目中的最大受益就是我们已经发展出了优秀的高级开发人员。值得注意的是，一年前还属于低级开发人员的那些人现在已经成为有力的技术领导者了。这归功于我们的做法：所有人在一开始就要对项目负责，我们鼓励人们相互交换职位进行轮训。轮训可能会有令人沮丧之处，例如一个系统分析员重新又作回开发人员。但是结果却是我们拥有了很多能够领导开发任务的技术领导者，这样，即使项目失去多位高级开发人员，项目的技术领导团队也非常的稳定。

原文转自：http://www.ltesting.net