敏捷开发管理

Quick-KillQuick-Kill项目管理项目管理*这是我今天在美国著名的Dr.Dobb开发网站上看到的一篇关注度很高的文章。我恰巧使用过文中讲的（或类似的）方法，而且效果不错，所以把它翻译过来作为参考。

原文：Quick-KillProjectManagement

译文：

Quick-Kill项目管理

作者：AndrewStellman&JenniferGreene

翻译：tianxinet（胖猴）－－最近致力于研究、介绍一些“最佳实践”

怎样进行敏捷的(smart)软件开发，即使面对“不可能的”时间表？

Andrew和Jennifer是“实用软件项目管理（AppliedSoftwareProjectManagement）”的作者(O'Reilly&Associates)。在可以联系到他们。

（译者注：文中leaddeveloper、lead都可以认为是teamleader，因为在小型团队中这些角色往往都是重合的，但也可以根据不同情况各安其位）

假如你是一个5人小组的leaddeveloper，你在一个项目中工作了几周，小组才刚刚上路。你的小组成员包括高级架构师到刚刚走出校门的初级程序员。这时候你的上司把你叫到办公室，告诉你高层主管刚刚在电话里训斥了他，他希望你的项目在昨天完成。而当终于完成的时候，已经超过许诺日期很长时间了。用户有一项工作要作，并且这个软件是必须的。如果软件不能工作，或不能工作的很好，你最好去更新你的简历。

这是你最后一次加入这种高压力状况的小组，这种项目是一场恶梦。小组成员已陷于错误的歧路很多天，你不得不扮演英雄，每个周末投入其中工作40小时去修正严重的设计问题。和高级经理开冗长的会议，顽固的bug好像永远不能搞定，经常工作到深夜。当小组终于交付了一些东西，用户却恨它。似乎用户点击每一个button都会有一个bug，而他们期望的特性却从没有在交付的软件中出现。

QuickKill

许多小组发现他们每天都处于类似的境况，leaddeveloper面对严峻的考验。leaddeveloper未必直接管理他的小组，但他负责把软件“送出门去”，他受到小组的尊重，当他作出一个决定，人们通常愿意追随他。但leaddeveloper的工组不是管理而是开发，他需要花费大多数时间设计方案、设计软件、构建代码。

Quick-kil项目管理由3个方法组成，这些方法让lead能够使他们的项目产物满足老板的期望和用户的需求：

•前景和范围文档（Visionandscopedocument）

•工作分解安排（Workbreakdownstructure,WBS）

•代码复查（Codereview）

这些方法中的每一个只需要少许时间来执行，并且可以帮助小组避免一些最常见和代价高昂的项目缺陷。使用它们，leads能极大的增进交付满意软件的几率。

前景和范围文档(Visionandscopedocument):6小时

如果一个小组不能真正理解所构建软件的“内涵”(context)，他们很可能在整个项目过程中都作出糟糕的决定。这些糟糕的决定浪费小组的宝贵时间去修正，如果没修正，又会导致项目不能符合用户的需要而损害小组和用户的良好关系。（如果）对项目的真正范围(scope)没有很好理解，小组唯一能预见的事就是被人“在屁股后追”（urgency），他们脱离了试图满足的需求。程序员能够看到自己的单个程序，但是脱离了大的构想。这是导致项目延迟和失败的最大单一原因。

幸运的是，有一个简单直接和容易执行的经验来帮助小组避免这些问题――花不超过一天的时间写一份前景和范围文档，并帮助小组避免数周的改写和错误的开始。

写一份前景和范围文档的第一步是和项目的干系人（stakeholders）交谈。不幸的是，谁是项目干系人不总是显见的。Lead应该找出最受项目影响的人――要么他打算使用软件，要么软件不开发出来他就有麻烦。干系人通常乐于谈他们的需要，这正是leaddeveloper――和其他小组成员，如果可能的话――应该和干系人谈的。和每个干系人谈不超过一个小时来获取他们的需求。

前景和范围文档应该是简明的、不超过两页（见下表）。通过和干系人交谈得到的所有信息应该加到“问题陈述”部分。

1.问题陈述

a.项目背景

b.干系人

c.用户

2.方案前景（Vision）

a.前景陈述

b.功能规格(Features)列表

c.将不会被开发的功能规格（Features）

（此处省略对此文档撰写的一些说明，见原文）

引用补上这段说明的原文：

Table1:Visionandscopedocumentoutline.

TheProjectBackgroundsectionisasummaryoftheproblemthattheprojectsolves.Itshouldprovideabriefhistoryoftheproblemandanexplanationofhowtheorganizationjustifiedthedecisiontobuildsoftwaretoaddressit.Thissectionshouldcoverthereasonswhytheproblemexists,theorganization'shistorywiththisproblem,anypreviousprojectsthatwereundertakentotrytoaddressit,andthewaythatthedecisiontobeginthisprojectwasreached.

TheStakeholderssectionisabulletedlistofthestakeholders.Eachstakeholdermaybereferredtobyname,title,orrole("supportgroupmanager,""SCTO,""seniormanager").Theneedsofeachstakeholderaredescribedinafewsentences.TheUserssectionissimilar,containingabulletedlistoftheusers.Aswiththestakeholders,eachusercaneitherbereferredtobynameorrole("supportrep,""callqualityauditor,""homewebsiteuser");however,iftherearemanyusers,itisusuallyinefficienttotrytonameeachone.Theneedsofeachuseraredescribed.

Theneedsoftheusersandstakeholdersarethemostimportantpartofthisdocument.Unlesstheteamunderstandstheneedsthatdrivetheproject,theymayendupwithanarrowfocus,causingthemtowastetimeaddressingproblemsthatareoflittleimportancetothestakeholders.It'seasytobuildgreatsoftwarethatsolvesthewrongproblems,buttheonlywaytobuildtheappropriatesoftwareisforeveryoneintheprojecttounderstandandagreeonbothwhyandhowthatsoftwarewillbebuiltbeforetheworkbegins.That'sthepurposeofprojectplanning.

The"vision"partofthevisionandscopedocumentreferstoadescriptionofthegoalofthesoftware.Allsoftwareisbuilttofulfillneedsofcertainusersandstakeholders.TheteammustidentifythoseneedsandwritedownaVisionStatement(ageneralstatementdescribinghowthoseneedswillbefilled).ThegoaloftheVisionStatementsectionistodescribewhattheprojectisexpectedtoaccomplish.Itshouldexplainthepurposeoftheprojects.Thisshouldbeacompellingreason,asolidjustificationforspendingtime,money,andresourcesontheproject.

TheListofFeaturesandFeaturesThatWillNotBeDevelopedsectionscontainaconciselistofexactlywhatwillandwon'tbebuilt.Beforewritingthesesections,theteamshouldwritetherestofthedocumentandhaveanopendiscussionoftheneedsthattheyaretryingtofill.EverysinglefeatureineachlistshouldbebuilttoaddressaspecificneedlistedintheProblemStatementsection.Oftentheteamcomesupwithafeaturethatseemsobvious,butthatturnsoutnottoreallyaddressaneed.FeatureslikethisshouldbedescribedintheFeaturesThatWillNotBeDevelopedsection.

工作分解安排(WorkBreakdownStructure,WBS):2小时

搞定了功能规格（features），开始针对这个功能规格工作之前，lead应该和小组一起提出对每一个功能规格的评估（estimate）列表。许多开发者在评估时会遇到很多麻烦，幸运的时有一些指导方针可以使评估过程简单可靠。

评估是重要的，因为它要求小组成员从头到尾考虑项目的每个方面。大多数程序员承认有这种不安的感觉：伴随着他们（原先）假定的任务的实现，原来（似乎）简单的问题会变得越来越棘手。如果其他小组的成员依赖这些工作，它可能把整个项目拖入混乱。好的评估经验可以避免经常发生的灾难。评估一个项目要求小组预先给出完成项目的步骤，并且提出每一步需要几天（或周，或小时），找出这些数字的唯一方法是整个小组坐下来考虑许多稍后在项目中可能被遗漏的细节。

做评估的第一步是把项目分解成一个完成最终产品要做的任务列表。这个列表叫做“工作分解安排（workbreakdownstructure，WBS）”。有许多方法把一个项目分解成一个WBS。leaddeveloper应该把小组成员组织在一起开会讨论任务列表。

一个有用的准则是――任何项目都可以分解成10～20个任务。对于大项目来说（比如航天飞机），任务是非常大的；对于小项目（象简单的计算器程序），这些任务很小。

一旦小组成员就WBS达成一致，可以开始讨论每一个任务，以使他们能够对每一个任务提出评估。在项目的开端，小组成员没有做评估需要的所有信息；然而，他们需要提出数字。去处理这些不完善的信息，他们必须做一些关于待处理工作的假设（assumption）。通过做假设，小组成员能够为后面可能添加的信息预留位置，使评估更加精确。

假设是评估的重要关键，如果两个人对完成一个任务需要多长时间有争执，很可能他们对产品和生产产品的策略做的假设不同。换句话说，任何争执通常都是关于执行这个任务需要什么，而不是完成任务所要做的努力。例如，为一个设置计算机时钟的工具给出相同的前景和范围文档（visionandscopedocument），但是一个开发者可能假设做一个命令行接口，另一个开发者假设做一个结合系统控制面板的图形界面。

通过帮助另一个程序员讨论这些假设，并且就他们的分歧达成临时决议，lead能够帮助他们就此任务达成一致评估。Lead应该一个接一个地提出每一个任务，并且小组应该决定每一个任务需要多长时间。每次遇到争执，就意味着有遗漏的假设，Lead应该与其他小组成员一道准确地指出那些遗漏的假设是什么。当这些假设被发现时，应该记下来。当讨论过程和更多的假设被记下来，小组成员会对项目了解的更多，并且将要开始就软件怎样被构建做决定。这帮助小组就每一个任务的评估达成一致。

最终WBS应该由任务列表、每个任务的评估、任务的假设组成。提出WBS中10～20个任务的假设大概会用去小组1个小时的时间。创建WBS以及做评估的总时间大约2小时。这对于一个5人小组的基本评估应该时足够的。但是，如果是一个大项目，就需要把项目分成很多块，然后每一块用2小时去评估。

代码复查（CodeReviews）:每次复查2.5小时

在一次代码复查中，小组检查一个代码样本并且修正它的任何缺陷(defect)。一个缺陷是一个不能象程序员想要的那样运行的代码块，或者可以改进的代码块（比如让它更易读或提高它的性能）。

执行代码复查是一个帮助小组构建更好软件的有效方法。除了帮助小组发现并修正bug外，代码复查对于程序员进行被复查代码的交叉培训(cross-training)以及帮助初级开发者学习新的编程技术是有益的。最重要的是，当开发者知道随后有人要阅读的时候会趋向于写更好的代码。

代码复查的第一个任务是选择检查的代码样本。复查每一行代码是不可能的，因此程序员要选择哪一部分的代码需要复查。如果复查的代码选择的正确，代码复查会是有效的。多数项目中，大量缺陷集中在相对小部分的代码中。如果代码选择的好，那么复查能帮助小组揪出缺陷，轻易地节省远比复查花费的时间更多的时间，如果这些缺陷留在软件中，稍后会需要更多的时间来追踪和修正。

对于leaddeveloper来说选择正确的代码样本并不困难。好的复查候选代码可能实现一个棘手的算法、使用一个难弄的API或者对象接口、需要特殊的专门技术去维护、或者可能使用了一个新的编程技术。这对于在一个软件中任何缺陷都将导致灾难的高风险部分选择代码样本是特别有用的――不仅仅是因为那些代码可能有更多的缺陷，还因为更多人会沿着这条线索去维护软件。当有大范围的修补时，引入缺陷的风险很高。

准备复查时，lead分发代码的打印稿（带有行标号）给每一个小组成员。小组成员分别花费半小时通读（如果可能并执行）代码样本一次，他们尽量指出代码是否真的在干作者想让它干的事。他们应该查找准确性、可维护性、可靠性、可控性、安全、可扩展性、复用性、效率问题。这些问题的任何一个都应该被看作是一个缺陷。每一个小组成员尽可能多的发现缺陷，并在打印稿上做标记。

准备完后，teamleader把大家集中起来开复查会议。代码复查开始是由leaddeveloper（大声地）阅读一段代码样本。他不是逐字阅读代码，而是做一个该代码块的简明描述。如果任何人（包括lead）不能理解这些代码在干什么或不同意给出的阐述，代码作者要解释这些代码应该完成什么，有时一个小组成员能够提出一个更好的、更加清楚的方法来完成同样的事情；通常只是大概说明这些代码的用途。

然后小组成员应该讨论代码中发现的任何缺陷，这时lead必须扮演会议的仲裁者。如果任何人发现一个缺陷，lead应该判断小组是否能够提出一个办法修正它，如果判断能，小组应该提出解决办法；如果判断不能，把它作为未决问题以便随后修正。另外，lead向包含复查记录(log)的表格中添加一行，每个发现的缺陷在这个表格中都有对应的行，每行列出包含缺陷的代码行号、鉴别人、以及一个怎样解决缺陷的描述（或者标记该问题为未决的）。在记录(log)的顶部，lead应该记下会议召开的时间以及复查的是哪一段代码。

复查会议应该不超过2小时。如果持续时间超过2小时，那么将来应该选择一个更短的代码样本来复查。会议结束后，lead应该把记录mail给小组成员，并且指定代码负责人修正缺陷。一旦缺陷被修正，lead应该复查更新的代码并确认代码被正确的修正。我觉得文中谈得也是属于比较理想的情况：

1、例如对于outsourcing的情况，双方确认需求等等就不一定会得到一个比较理想的结果。

2、项目评估，对于新技术下的应用，如何评价项目成员单体评估的有效性，合理性等等。

3、codereview,作为leaddeveloper,手头还有相应的开发工作，这codereview的时间还不得不衡量一番。

4、还要充当调速器，抵御客户和领导等外来造成的波动。

一个在deathday前挣扎的人说(那个人是我):"

1.知道自己要干什么(多花点时间真的很值)

2.估计干完一个东西要多长时间(估计的人需要有经验)

3.完成这个BUG的重要度(如有多个BUG在等待时就非常有用)

4.死亡时间是什么时候.(担心是没必要的作不完是肯定的)

5.非常恶心的备用方案是什么(如人工输入,凭闭此功能)

"

以上如果对你有帮助那么我这几天的辛苦也没白废为你的项目加入一个阶段--技术研究为你的项目加入一个阶段--技术研究

--项目管理的一种“最佳实践”

摘要：以一个明确的“技术研究阶段”来提高开发效率、规避开发风险、提高项目管理的可控性，是一个简便易行的“敏捷”项目管理手段。

1、什么是“技术研究阶段”

这是我在项目管理实践中总结出的行之有效的一种“最佳实践”，技术研究这个词很自然就能理解了，“技术研究阶段”通过本文的描述也很容易理解。关键是“实践”。

2、明确一个“技术研究阶段”的动力

*规避技术风险

*提高开发效率

*提高项目管理可控性

这是在项目管理中实行“技术研究阶段”最原始的动力。

3、“技术研究阶段”的适用情况

有几种比较典型的情况非常适合加入“技术研究阶段”：

*项目中引入新技术、框架

*项目有复杂的新型需求（比如：未遇到过，而且不确知与实现相关的性能问题，等等类似情况）

*项目开发团队“以老带新”

*锤炼、优化已有的相关技术积累，以应用到当前项目

这几种情况是我验证并收到良好效果的，并且我认为可以适用但不限于以上情况。

4、怎样开展“技术研究阶段”

4.1什么时候实行“技术研究阶段”

项目的开发团队一组建，或者主要全职开发人员一到位，就可以开展“技术研究阶段”。可以和需求分析并行，最好开发环境、平台等已经选定。

4.2“技术研究阶段”实行原则

一定要明确这个阶段，参与者有明确的目标和任务，可以动用“卑鄙”的考核手段（主要是提高重视程度，而不是考核）。

目标和任务由项目经理、teamleader、资深开发人员等共同讨论决定。以老带新的情况下，“老人”为主要责任人，同时也负责指导“新人”。至于指导手段，什么结对编程等等都可以。

目标任务要明确下来，你写在公示的白板上可以，用邮件发任务书也可以，总之要让每个人明确自己的研究任务、时限。

4.3“技术研究任务书”

上面提到，用来明确目标任务。载体可以灵活，格式要简单明了，任务、时限、责任人是核心内容。不要放太多东西。

4.4研究目标实现手段和提交物

一定要结合眼下项目的具体业务场景。

业务场景由项目经理、核心开发人员等（团队不是很大的话最好是全体人员参加）选定典型、难点场景，不要很完整，针对估计的技术实现难点最好。

所有类型的技术研究，提交物都是一个现实开发、运行环境下的demo，不关心界面友好等等一切修饰性东西，最关心的是实现该场景的技术难点，它不必是bugfree的。

4.5“技术研究阶段”的“研究结果宣讲”

这是非常重要的一个环节，每个人，或者每个研究任务都要有一个代表，讲解自己的“研究成果”，项目组开发团队都要参加。

这个阶段是否实施取决有公司在管理面上的宽容程度.

针对个人经历的过程，觉得有几点很重:

1.技术研究要分类，比如那些是尝试性的、那些是专业性的

2.技术研究的人选十分重要,一定要找对人，否则只能是浪费时间或使这个人松懈下来，从而影响整个团队的士气

3.技术研究需要有一个合理的时间计划

4.技术研究的结果要整理成文档、程序等

5.技术研究完成后必须针对所有人员作一个汇报和培训，授课是一个很好的方法，这样可以最快速的将新技术推广并且也可以考核研究人员的能力

6.技术研究可以最为对员工的奖励措施关于项目管理方面的一些思考

最近一直有所思考项目管理方面的事情，也是在心中考虑一些，正好今天得空，写一下，以防自己忘记，也巩固一下自己的思考成果^_^。

对于项目leader或者项目经理，对于一个项目来说最大的事情，莫过于管理，管理管理有管有理，不能放任自流，也不能过于不信任自己的队员。项目重要的事情就是要有一个目标，一个先期目标，也就是要达到什么。想想也是废话，不过仔细考虑一下这个就不是废话了，很多项目上来就是你作吧，别的什么都不说，做成什么样子，要搞成什么样子也都没说。这个我觉得还不算大问题，只要在后面管上加以动作的话，那么就应该没问题，如果后面管还没有的话，那么时间质量效果上，可能都是问题。

有了目标，那么剩下的就是要生成计划，一个粗略地计划，和一个近期短暂的计划，来保证项目前进。粗略的计划为纲，细的计划为一个里程碑，最好是一个礼拜为一个点，来划分，如果心中明确的话，最好做出一周细的同时，把下一周粗的也给制定出来。制定出来计划后，就要及时检查，及时调整，如果有时间的话，最好一天一次检查，没有时间的话，至少要在一周结束的时候，检查一下。《程序员修炼之道》里面有句话，很符合项目的，项目进展就像是开车，你需要不停的得到路面的反馈，得到眼睛给与的反馈，进行调整方向，速度。大体是这个意思，我觉得项目确实是这样，不能制定了目标，就闭着眼睛开车，速度方向放任自流，这样车早晚开到沟里面去。

项目三个要素，速度，质量，频率都要把握好，速度要有，质量要把握，同时频率也要把握好。不是车一直开大油门就好，短时间是可以的，长了，车就毁了，一定要把握好频率，该休息休息，该工作工作，要让项目最大的成本（人）维护好，只要这样，才能更好的发展。过一段时间，需要让组员释放一下心情，释放一些积怨，让组员休息好，才能工作好。只有积极调动了组员的积极性，才能事半功倍。并且，千万不要打消组员的积极性，那绝对是事倍工一点啊！科技以人为本

测试，这一点是我一直在思考的地方，也是我一直在努力做的地方，现在还没有做到TDD，也没有做到全面的测试，这点一直是我的一个遗憾，我觉得一个项目如果想要成功的话，还是需要一个专职的测试人员，如果进行TDD的话，如果首次，还需要一个测试辅导人员，我一直在这方面努力，现在只是稍微有些小的成果，但是时间和精力问题还是进展缓慢，这点只能在后面自己一点点的努力。

现在说说管理的事情，项目需要管，需要对项目管方向，频率，质量，人员等，还需要对项目理，需要理顺项目的各种复杂因素，政治的，其他等等，需要理一下，项目的问题，不能盲目的管，需要不停的整理自己的管的方针，策略等等，及时调整自己的方案。

作为管理者，不需要事无巨细的什么都过问，但是关键的时候，一定要做出一些抉择，不能让组员总是摇摆不定，这样的话，会耽误时间和打消组员的积极性的。管理者，关键就在于管理上，想想唐僧，我终于明白他为什么是师傅了，他的责任就是领导。他的技术在某些方面是最差的（打怪），但是管理却是一顶一的好手啊，可以把三个个性鲜明的人物管理的井井有条，这个就是管理才能啊。。。

敏捷开发的必要技巧完整版亲身体验软件项目管理中的误区

随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。计算机软件开发从“个人英雄”时代向团队时代迈进，计算机软件项目的管理也从“作坊式”管理向“软件工厂式”管理迈进。这就要求软件开发人员特别是软件项目管理人员更深一步地理解和掌握现代软件工程的理论方法，完成思想观念上的转变。笔者在此分析了10个在现代项目管理中思想观念上容易陷入的误区，希望能够抛砖引玉，引发大家更多的思索和讨论。误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致，以后对需求的修改几乎是必然的。分析：这是一种非常危险的思想。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者时间进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽早地对需求变动问题进行沟通。(范围的核实和项目验收都要根据范围基准进行。因此前期的范围说明书和范围的基线至关重要)误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不表明“软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍的代价；在软件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少，容易被实现。(不应该称为误区了，现在估计谁都不会认为需求可以持续不断改变)误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。分析：与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移——不是着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3%，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%。(这个跟软件项目的规模密切相关。对于规模小于2万行代码的，或者说采用敏捷或快速开发的，或者说架构已经确定的改进型号项目，编码时间至少要占30%；而对于源代码规模超过50万行的大型软件项目,重点则是在需求和系统设计上面，编码时间一般为10%)误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。分析：通常伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。工作量是很大的。所以切合实际的方式应该是对一般的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。(应该深刻理解源代码就是设计的一些重点观点和思路，因此详细设计输出的代码模型一般是不抛弃的，编码人员可以直接在该代码模型基础上进行编码)误区5：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。分析：软件程序测试可以分为“白盒法”和“黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。如何解决这个问题？一方面需要提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白盒法”测试的最佳人选）。(估计很少有人这样认为，所以不应该称为误区).误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。分析：在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想提高公司的软件项目管理水平，这就需要提高公司的整体参与意识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要研究部门（技术委员会）指派专家协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。(干系人管理很重要,同时CMMI强调的集成项目管理也说明了这一点)误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发风格、团队协作氛围；那么“新人”的加入是有益的。否则，可能会“好心好意做坏事”。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队不得不分出人手对其进行与项目有关的技术/业务培训，更重要的（也是难度最大的）是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能使项目进度更慢。(可以辩证的看，组织的成熟度越高，复用越高，该方法才是可能的方法)误区8：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在“软件作坊”时代，这是一种普遍使用而且效果不错的方法；而在“软件工厂”时代，这种方法却带来各种问题，有时甚至直接导致项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发生了根本的改变——最注重的不是其对某项专业技术的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问题，这和定薪制度有很大关系。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高的，但不一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。(这里跟工种无关，更相关的是效率和产出,但去很难推行)误区9：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。分析：这是一种“官僚”的想法。实际上程序员作为团队中的一员，他不仅仅是在打一份工，更重要的是在参与一件“作品”的创作。在体味工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员对“成就感”的追求，应该向每一个人详细描述最终“作品”将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把这个消息告诉每一位项目成员。实际上，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作效率。误区10：为了保证项目继续，为了留住核心程序员，加薪吧。分析：加薪可以说是很多企业在挽留程序员时所使用的常用方法。这一招可能暂时奏效，不过往往是人留下来了，但副作用也来了——加薪的人未必见得多干活，没有加薪的人却开始消极怠工了。其实，项目的进行过多地依赖程序员的个人技术是“作坊”时代沿袭下来的“陋习”。既然IT行业人员的流动是无法控制的，现在项目的执行应该更加注重团体的力量，应该更多的考虑公司整体技术水平和核心技术能力。例如形成公司自己的专家知识库，类/函数库，第三方控件库，拥有自主版权的开发平台等。另外，实际上程序员萌生去意的原因很大程度上不是薪水，而是缺少激励和尊重。这需要项目经理使用“老土”一点的办法，找适当的时机对程序员做一做思想工作，向其描述项目的美好未来，让其感受关心和尊重。总之，要从多方面着手保证项目的顺利开展，而不是简单地加薪。项目回顾：一个开发人员的观察与思考项目回顾：一个开发人员的观察与思考

胡健

项目背景

这个项目的客户是欧洲一家人寿保险公司。该保险公司目前进行的一个计划是对现有的业务流程（businessprocess）和IT系统进行较大规模的改造，以适应新的市场要求。我们的项目是这个计划的一个组成部分，它的目标是建立一个浏览系统与保险公司的后端保险管理系统相连。这个浏览系统用Web浏览器作为用户界面，以取代目前使用的字符终端界面。2002年初，公司的有关部门（专门作金融服务）曾作了一些可行性研究工作。项目于2002年四月底正式启动，主要的开发工作于10月底结束。然后由另一组人马进行用户接收测试（useracceptancetest）。

技术与系统构架

系统采用J2EE技术，系统基本上是三层（3-tier）结构，即Web接口（webpresentation），应用逻辑（applicationlogic）和后端服务器（backend）。

系统需求与规范

该项目主要有两种文档提供给开发人员：一种是系统功能描述，由一系列的模块组成。每个模块类似于一个usecase，主要给出了该模块需实现的屏幕/窗口（screenshot），并一般地描述了这些屏幕上的操作以及它们之间的切换。这样的模块描述文件在项目中被称之为“故事板”（storyboard）。“故事板”由业务分析人员（businessanalyst）会同用户产生。另一种文档是与后端服务器接口的规范说明，如命令格式，数据格式等，由后端系统设计开发组提供。按照项目规定，两种文件都需要经过充分讨论并基本稳定下来之后，由相关负责人员签发（signoff），然后交给开发组。

项目团队与工作地点

项目组有14个开发人员，2个业务分析人员（businessanalyst），一个项目经理。主要开发组在英国（10个开发人员），项目经理和其余人员则在客户所在地（与英国有一小时的飞行的距离）。

工作笔记

由于工作习惯，我一般每天都作工作笔记。而在这个项目中前两个多月中，我也每周都写一篇小结，主要是对项目运行的观察（所计述的都是对我所在的公司本部开发组而言）以下便是稍作整理后的前十周的小结（略去了公司和人员的名字）。这些笔记可能显得有些杂乱和琐碎，列在这里的主要目的是想忠实地把我眼中的项目进展情况展现出来。

第一周

*开发组成员逐步聚集到项目组所在地。我们十来个人都坐在一起，边上一个大白板。这种坐位设置非常利于交流，特别是Cockburn所称的“渗透”式交流。各成员的技能方面也各有所专，如Java，EJB，JSP等。

*项目有个时间录入跟踪系统（timetracker/timesheet）。每人需录入每天所做的任务和时间。这主要用于项目管理，而这些历史数据也是对新任务进行规划评估的基础。

*这周的主要工作是设置工作环境。每人一个WindowsNT或XP2000作为工作站。我们选用的IDE（IntegratedDevelopmentEnvironment）是NetBeans。选用NetBeans的主要原因是经费问题（NetBeans是开放式源码并免费）。源码控制是用的MicrosoftSourceSafe。源码库放在一个项目所用的专门服务器上。而项目的文档材料，如需求分析，系统架构以及开发管理文件，如时间进度表等。

*虽然项目已决定使用J2EE技术，但具体的系统架构仍然需要建立。初步的选择是一个应用框架（applicationframework）。这个框架是由我以前参加的一个项目发展而来，我对它的起源和演化都相当了解，因此我也开始对这个框架进行评审（review）。

*我注意到没有单元测试环境，便开始作一些这方面的工作，因为组里只有我有过建立及使用单元测试的经验。

第二周

*我建立了一个基于JUnit的单元测试框架，并写了一份2页纸的简短介绍，包括单元测试的概念与实践，以及一种称之为“MockObject”的技术，因为我认为我们的系统需用到这种技术。

*本周有一次角色分配。一位精于JSP的同事将主要负责前端（front-endpresentation），两位对项目所涉的后端有较多知识并参加过可行性研究的同事将更多地与在客户地点的businesspeople（业务人员）打交道，一位对编码标准（codingstandards）有浓厚兴趣的同事负责收集大家在编码方面的问题并执笔编码标准文档，还有一位精于Ant的同事主要做工具开发与配置管理（configurationmanagement），等等。

*我们的编码标准主要是以SunMicrosystem的“JavaCodeConventions”为蓝本。另外，客户要求源码中所有的publicandprotectedmethods必须要有JavaDoc说明。一些与我们的特定系统有关的问题，如命名惯例（namingconvention），将随着开发进程不断地编入文档中。

*大家对现有的“故事板”进行的讨论分析，并分解出一些具体任务，然后大家根据自己的角色和兴趣signup（“认购”）任务并开始设计与编码。

*关于源码控制与源码库，大家同意每天早上更新自己的工作版本（workingcopy）。如果要修改或加入文件，在checkin之前，一定要保证整个源码能通过编译。

第三周

*大家继续上周的设计与编码工作。同事们似乎都是Cockburn所说的“goodcitizen”，工作中人人争先，个个奋勇。

*随着编码的进展，一个问题开始出现了。我们这里没有后端系统，所以不能对开发的程序进行完整的测试与集成。

*星期四，项目安排了一次电视会议（videoconference），参加者是我们这边的成员与在客户那边的成员。两边的同事通过电视见见面，每人作一简短的自我介绍。然后主要是讨论了当前开发中的问题。最严重的问题包括需求与规范文档没能按时签发（signoff），以及我们这边没有测试环境。

第四周

*由于客户对我们选用的应用框架（applicationframework）仍有疑虑，应客户要求，我们公司找了一位有着非常丰富的开发经验的、并且在我们目前所用的应用框架（applicationframework）上做出过系统的技术权威向客户解答他们的问题。

*新来的技术权威是位敏捷方法（agilemethodology）的热心者，我们在他的建议下准备采用类似XP的过程，首要目标是向客户，也是向我们自己显示出我们能出活（wecandeliver）。周一下午，全组开了一个两小时的会议：

o确定了要实现的一个很基本的功能，该功能其实大部分的编码已完成。

o围绕这个功能，分解出若干需完成的任务，如：源码审查（codereview），源码修改，单元测试，建立“哑”（dummy）后端以作为初步功能测试与集成，找一台空机器以作系统建造与演示，等等。

o大家根据自己的特长与兴趣来“瓜分”把这些任务。

o根据每人对完成自己任务所需时间的估计制订出工作流程与进度，以0.5天为一单元。

o根据进度表，“交货”时间为下周四中午12:00点。届时，我们需提供一份releasenotes，上面将列出系统安装的步骤。按照这些步骤，我们需要：

+在一台只有操作系统的空机器上建立运行系统所需的环境；

+编译源码并安装系统；

+运行系统并演示所完成的功能。

*因为下周一周二放假（庆祝女王登基五十周年），时间非常紧迫。大家开足马力，开始工作。

第五周

*尽管大家尽了最大努力，星期四的期限没能完全达到，其主要原因是系统安装上有些没预料到的困难。但最终在星期五中午完成了所有的要求并进行了系统演示。

*星期五下午全组会议，主要是对这一周期中的开发过程进行讨论，特别是那些感到最困难的事情。大家发现以下这些任务花的时间比预想的多：

o熟悉应用框架和系统架构；

o建立“哑”后端服务系统以作测试环境

o建立单元测试

o系统安装。

第六周

*根据上周的讨论，编码标准（codingstandards）进行了更新。

*对第二三周所作的工作重新进行了讨论并制订了新的进度表。这个周期的工作其实包含了三个usecase（或“故事板”），每块“故事板”基本上由两个人负责。其他人则主要完善单元测试框架及建造“哑”后端系统。

*本周工作中发现，有一处设计/模型需修改以适应新的功能。多数人被吸引到讨论中并提出了若干方案。我提出用一种“角色模式（rolepattern）”，因为我认为它非常适用我们现在的情形。

第七周

*关于修改模型的讨论继续，最后是决定采取一个简单的方法（虽然hacking的味道很重），这主要是考虑到系统的特点和“简单性”原则。（有趣的是，我离开项目组后，有位同事做后续开发，又来和我讨论rolepattern，并且决定使用一种更复杂的rolepattern）

*本周的开发工作中也发现了“故事板”的一些问题。因为“故事板”不是精确的规范说明，因此在编码时会遇到一些含糊不确定的地方，需要询问用户或businessanalyst。

*由于新的classnamingconventions（取名规则），对有些部分的源码进行了重写。这是件很花时间与精力的事情，特别是要非常仔细（据说有些IDE支持这种工作）。

第八周

*由于发现了一个utilityclass的潜在的问题，大家同意需要用新的方式来使用这个class，并对现有的源码进行核查及修改。

*在一个模块的编码和单元测试基本完成之际，最令人恼火的是发现描述这个模块的“故事板”还在更新，而这个“故事板”在我们决定开始干这个模块之前是已签发（signedoff）了的。没有办法，只得重读这块“故事板”，并对源码以及单元测试进行相应的修改。

第九周

*这周的主要工作是在“哑”后端服务系统是建立新的“哑”功能和数据，以便能对新开发的模块进行“集成”与功能测试。这实在是一件太花时间的活。

第十周

*非常不想看到的需求改变又来了。又是重读新的需求说明，修改相应的源码。而在与业务分析员的讨论中，又发现我们对一个“故事板”中的一处功能有不同的理解。最后，当然是得根据业务分析员的意见，对源码进行修改。

*最后，终于作了源码审阅，并根据审阅者的意见对源码作了整理，然后整理出设计文档。把这些源码与文档传给在客户那边的同事们去和真正的后端服务系统连接并测试。

第三至六月

第3－6月基本上是顺着第6－10周的路子走，但也有一些明显的变化：

*系统调试。建立“哑”后端作测试被认为有些不值得，因为花的时间太多。最后两个月的做法是等一块“故事板”在我们这边完成后（编码、单元测试、源码审阅），派一个或两个人飞到客户那边去待3－5天作系统调试。这样的花销也很大，但客户似乎并不十分在意。

*源码质量。源码中需“重整”（refactoring）的地方被不断的查找出来并写入到文档中，编码也在不断地增补，源码审阅变得比较正规，并有一份专门的文档。审阅者对源码进行审读后，需列出需修改或进一步说明的地方。程序员需对每一处进行相应的修改或说明，签名后交给审阅者签名确认。审阅的标准主要是编码标准和源码“重整”（refactoring）文档。

*进度规划。随着开发的进展，对每个新的“故事板”的规划和进度表制订越来越精确。

讨论与思考

下面的讨论将主要围绕一些XP的实践原则展开。

用户在场（Onsitecustomer）

尽管开发组的一部分在客户地点，但主要的开发工作却是在公司本部进行的。这里没有用户，没有业务分析人员。这点显然与XP的原则相违背，而其造成的不利影响贯穿于项目始终。首先是对制订计划与进度表的影响。一般来说，在制订计划之前，开发人员需要花一两天读一个“故事板”，然后作出初步估计。故事板简单易读，能使人很快地大致了解一个功能模块的需求。但是，很多地方比较模糊，有些地方在阅读文档中仔细一点就能看出来。这时最好有用户/业务人员在场，马上就能澄清。象我们靠电话和email，时间花的多，还不见得能说得很清楚。

第二个影响要更严重一些。“故事板”中的不确定性有些在读故事板时能发现，而有些就只能到了编码的时候才能暴露出来。由于业务分析人员在客户那边，只能靠电话和email，其质量当然不如面对面的讨论好。特别是当不能及时得到答案而时间又紧迫时，程序员往往得靠经验和“推理”作一些假定。如果是错的话，就只能在功能测试和用户接收测试时再改了。

另外一个类似问题是与后端系统通讯的规范说明，这是由另一个项目组提供。那么我们与他们之间也是有个沟通的问题。而糟糕的是该项目组也是在客户那边，因此只能靠电话和email。总之，我觉得这个项目的实践是从反面证明了用户在场的重要性。

制订计划与进度

如上所言，制订计划和进度表是从阅读“故事板”和规范说明开始。经过若干电话与email的往来后，制订出一个计划，主要是把需完成的模块进一步分解成一些任务，以及估计完成每个任务要花的时间，以0.5天为一个单元。该计划是一个spreadsheet文件，放在项目的文档服务器上，大家随时可查看。

“并行开发”

我们的项目有一点和正规的usecasedriven的过程不太一样。一般是一个周期主要是做一个usecase。在我们项目中，一个“故事板”大概算一个usecase。如在“工作笔记”中所言，在项目走上“正轨”后（从第六周开始），一般是2－3人做一个“故事板”。所以，一般同时可能有两三个“故事板”在进行。每个“故事板”的周期约3－4周。这样做的好处是提高了生产率，但我觉得这样做的前提条件是每个开发人员必须是有足够的经验与技能，还有就是熟悉开发过程（第4－5周的实践是非常重要的）。

单元测试

单元测试是客户的一个要求。在前两个月，我们做还有些“过分”。我们是用NetBeans提供的工具对每个类（class）都生成相应的JUnit测试类（testclass）。对一个类而言，其中的每一个public和protectedmethod都在testclass中有对应的一个testmethod。而这个testmethod里只有一个fail语句。这样强迫你用测试来替换这个fail（当然你也可以把它删掉）。结果我们发现花了很多时间去写getter和setter的测试，实在不值得，因为这些methods非常简单。我们因此说服客户，允许我们不用对getter和setter些测试。不过，我倒是发现，对getter的测试，实际上是在测试相应attribute的初始值。设置初始值常常被忽略，而会在运行中引起一些问题，如最常见的NullPointerException。

单元测试通常要求把被测的对象孤立起来，即测试不要用到其他的类。而实际中，一个类往往要用到其他的class提供的服务来完成自己的功能，最常见的如使用数据库或一个远程服务。单元测试需要切断这种依赖性，即一次只测试某个我们需要测的类。这可以利用MockObject（“模拟对象”）技术来达到，例如，用一个mockservice来代替真正的service，而我们可以很方便地对这个mockservice进行状态设置。在我们的单元测试中就大量地运用了这种技术。网上有一些工具可用来帮助产生mockobjects，如MockMaker，可以节省一些时间。

总的来说，单元测试的确提高了源码质量。那些逐步建立起来的testcases，我感觉是起到了一张“警戒网”的作用。源码修改需要作改动时，这种作用特别明显。不过，我们也注意到，对一个类进行完整的单元测试所花的时间往往不少于编码的时间。因此，一个很重要的问题是决定测试到什么程度。XP的建议是对“可能会出问题”的地方要重点测试。但什么是“可能会出问题”的地方则需视具体情况而定。

系统集成与功能测试

由于我们这里没有一个真正的后端系统，因此没办法作真正的集成与功能测试。在项目的前半期，我们曾建立了一个“哑”后端，这的确对我们的测试/调试起到了很大作用。但是，当越来越多的功能加入后，“哑”后端变得越来越负责和不可维护。最后，我们只得放弃这种做法。

项目的管理层曾作了很大努力，想使我们这里能直接连上客户那里的后端系统，这在技术上是完全没有问题的（毕竟这是网络时代）。但不幸的是，这个合理要求没能得到满足。所以项目后半期，当一个“故事板”的的编码与单元测试完成后，一般由编码者或测试者飞到客户那里去做集成与功能测试。

结对编程（pairprogramming）

在我们这个项目的实际中，pairprogramming与“传统”上的意义有些不同。首先，因为我们坐得都很靠近，如果某人有什么问题，只要一叫，一般就会有人跳起来跑过去帮忙。这可算是一种“基于解决问题”的pairprogramming。

另外一种更主要的是方式是编码与单元测试的结对。由于测试者对于如何使用一个（待测试）的类一般不会有着与编码者完全一致的思路，这样对于发现问题是很有帮助的。另外，由于测试者一般都会在测试时详细阅读源码并与编码者讨论，这对于改进一个class的细部设计与实现也是很有用的。但这种审阅与源码有所不同，这里主要是着重“逻辑”的正确与有效，而源码审阅则偏重于源码的风格与标准的统一。

还有一种方式可称之为“结对排故”（pairdebugging），我发现这种情况多在系统功能测试中出现。如果在测试中出现一个问题（bug），找来找去找不到（因为这时涉及的东西的较多），搞得昏头胀脑。那么最好是抓一个同事到屏幕边上（最好不是和你搞同一个部分的），然后给他讲讲是怎么回事。他可能会一眼看出问题所在（如果他曾遇到过类似的问题），或者会从另一个角度来提供一个思路。另外，常常也有这种情况，来帮忙的可能只是听着，而你在讲的时候可能就自己发现问题了。我想这是因为你在给其他人解释一件事的时候，你实际上是在强迫你自己清理自己的思路，而这肯定是有助于找到问题的（特别是在昏头胀脑的时候）。

编码标准（codingstandards）

项目开始的时候，我们就决定采用Sun的“JavaCodeConventions”作为我们编码标准的蓝本。随着项目的进行，大家不断地讨论并同意加入一些与项目有关的标准，例如：

*所有的classes和所有的publicandprotectedmethods都必须要有JavaDoc注释；

*对于packages,classes,variables的命名标准；

*如何使用集合（collection）类型，如变量的类型需是interface，如Map而非HashMap；

*如何使用实数类型，如规定用double而非float；

*如何使用logging（我们使用log4j）；

*如何处理exceptions，等等

源码审阅（codereview）

源码审阅一直是项目的要求之一。但在项目的前半期，这点做得不是很正式。当然，一个主要的原因是大家想尽快地做出一些功能。这样造成的一个后果是源码开始有些杂乱并且不一致。项目后半期开始比较严格地进行源码审阅，并且规定一个“故事板”的源码在进入系统测试之前一定要有正规的源码审阅。

进行源码审阅时，审阅者一般是根据编码标准上所列的条款对源码进行检查，看是否符合标准。同时，也可对一些具体实现上提出自己的看法。这些意见用一张专门的表格一项一项地记录下来，交给编码者修改或给出进一步的说明。最后，审阅者对源码复查，对每一项进行核对，满意之后签字认可。我们的经验表明，这样的源码审阅大大地提高了源码的质量以及可读性和可维护性。另外一个作用是使refactoring得以经常及时的进行。

源码重整（refactoring）

我们项目里，refactoring基本上是与编码标准和源码审阅同步进行的。项目的前半期，基本没有refactoring，尽管有些不好的码段或实现被不断的发现并记录在案。当然，主要原因还是由于大家想集中精力先做出一些功能。在项目的后半期，开始和源码审阅一起较严格地执行。和源码审阅一样，这样做的结果是大大地提高了源码的质量。

以上这些就是对这个项目的一些观察与思考。总之，对开发人员来说，这个项目有许多的不确定性，这主要反映在需求与规范文件上，也反映在相关项目组之间的协调（或扯皮）上。项目组分散两地，测试环境的缺乏都是开发中的很大问题。在这种情况应用XP的实践原则，如密切沟通，单元测试，源码审阅与重整，能有效的（也许是艰苦地）推进项目的进展。

后记

记得几年前曾看过一篇文章是讲中国的MBA的教育的。大意是说工商管理是个实践性很强的专业，做MBA的一项主要工作是做大量的个案分析。而目前中国似乎还没有足够的个案，有待于现在的MBA们毕业后在工作中去积累。这些积累起来的个案将是今后MBA们一笔宝贵资源。由此想到软件开发，何尝不是如此。软件开发是个实践性很强的群体/团队工作，这点从三十几年前“软件工程”的提出时，人们就已经认识到了。提出的方法也是层出不穷，但真正在实践中运用的并不多。这几年出现的以XP为代表的agile方法兴起，主要原因就是在于它们是从工程实践中提炼出来，而其可行性至少在一定条件下或范围内又为他人的实践所证明。那么我觉得现在最重要的不是高谈阔论，而是扎扎实实的实践，即在了解这些原则后如何在工程实践中加以运用。更进一步，如果能把这些实践记录下来，加以总结，这对自己和同道都是一件好事。基于这样的想法，在下不避琐碎，把自己对一个项目的观察与思考写下来，期望能抛砖引玉，看到更多的同道能把自己的经验写下来，与大家共享。使用最小化的软件开发过程从《Java敏捷开发》中获得的启发，为了敏捷开发需要使用最小化的软件开发过程，这个过程只要保证项目有效进行和满足客户需求即可。

书中给出了一个简单范例开发过程：

1.项目初期

*非正式业务需求和问题的讨论

*项目开始

*定义问题描述(如，核心用例)

2.项目探索阶段

*探索业务主要的概念(建立领域模型)

*建立基本原形和故事板(针对用户界面程序)

*定义项目范围(定义项目中应该做的事推迟做的事)

*定义下个阶段的用户故事

*建立非正式白板上的架构图

3.计划

*下个版本系统的计划

*建立公共的业务词汇表

*制定下个迭代中的迭代计划

*建立系统规范(命名规范，代码规范，checkin/out规范，集成规范)

4.在迭代中进行渐进式的软件构建过程

*进行周期大约为两周的迭代开发，在第0次迭代中进行环境安装和概念证明

*每次迭代之前进行迭代计划会议，选择下次迭代中要实现的用户故事

*基于用户故事对开发者任务进行最佳估算

*用户对具体需求进行验收测试，开发者对这些需求都进行单元测试

*开发者在设计和开发时需要用户的积极参与，便于沟通

*在通过验收测试后，每两周发布一次成品代码项目的范围

定义项目的范围方式很多，有时是客户简单的描述的一两句话。也许会使用图示做为结构化的定义表述。有些组织还要进一步与开发团队签署服务水平协议书(SLA).还可以进行非功能性需求讨论，这也可以帮助定义项目的范围。

可以在一张表里面列出什么是范围里需要的，什么是范围中推迟的（甚至是派出的）

系统维护

它是指程序进入维护状态的阶段，这个阶段可能包括对用户的培训，按照需要进行小的性能增加和修改（以用户故事的方式）。可能客户还需要在开发一个版本，在这种情况下，你需要从项目的探索阶段从头开始。3楼

\o"lokvin"lokvin

2007-03-16

引用产品迭代开发阶段（渐进式构建软件）

迭代开发也许是一个你很熟悉的术语，但不同的人使用不同的软件开发方法，对迭代和每个迭代过程所包含的内容的理解是不同的。

在这里，迭代开发意味着每次迭代都要有设计、编码、用户验收和生产就绪代码的部署，生产就绪的代码要部署到生产环境中。如果在一个大公司，经常部署到生产环境并不是很现实，需要先把它部署到验收环境中，只要用户验收通过，就可以进入下一个迭代过程了。总之，每次迭代需要有以下事件:

*开发人员对开发任务进行评估，制定下次的迭代计划；

*客户和开发人员事先的沟通交流；

*设计--包括CRC卡，UML图等

*编码--测试先行，按照要求重构代码，数据库，程序结构，进行系统优化；

*用户验收测试(UTA)

*迭代后的版本部署到生产环境或验收环境中，这个过程也叫做发布一个小版本。

按照这样的方式进行迭代，可以不断地建立项目的下一个版本，假定一个项目我们估计会在3个月内完成，我们会把它分解成每2周一次的迭代，所以大约会有6次迭代开发。每次迭代的截止时间是工程进入下一个阶段的时候，迭代的小版本成为了生产就绪的代码（稳定的代码），即使他只是完成系统的一个子集。2楼

\o"lokvin"lokvin

2007-03-16

引用项目计划阶段

计划对于不同的人来说具有不同的意义，一般要包含以下部分：

*版本发布计划--他实际是为系统的下一个版本所做的计划，他可以很容易的被表单程序、字处理程序、HTML表格汇总在一起。他列出了在下一个版本中将要包括的所有用户故事，并且按照不同的迭代分组，一般的，一个发布是有固定时间要求的，最短1个月，最长3个月，2个月是一般比较好的选择。

*迭代计划--在每一次迭代之前都要有一个迭代计划，包括下一次迭代中客户需要实现的用户故事，迭代时间一般也是固定的，最短1周，最长3周，2周一般是比较好的选择。

*规范定义(代码，数据库，过程)--在开始任何开发之前，为一些东西制定规范来统一化是非常好的做法。例如，这些规范包括：编码约定、数据库命名约定和过程（包括构建、继承和发布）约定等。

建议应该经常和用户一起制定迭代和发布计划。记住，成功地项目是那些用户能够积极参与的项目。1楼

\o"lokvin"lokvin

2007-03-16

引用项目探索阶段

一般探索阶段包含一组探索性活动，帮助你更好的理解客户需求和接下来该如何设计和构建程序。

*域建模--领域建模可以帮助你定义主要的业务概念（实体）和他们之间的关系。

*用户接口原形和故事板--有些最初的版本页面可以使我们清楚地知道用户对产品界面的要求。而一组相关的界面流程图就是故事板。

*用户故事--一些用户故事的完成标志着项目的开始，他们组成了要发布的第一个版本的内容。用户故事(从某种意义上讲与要做的事相似)由用户编写，用简短的语言描述出用户定义的产品功能。注意，虽然你所收集的用户故事数量由项目来决定，但是应该保证他是足够好的并且是有用的。

*范围定义--预先定义项目的范围可以使你知道什么需求是现在需要开发的，什么是可以延期的。他也阐述了用户对软件的期望。

*分析--这是个综合性活动，如，在白板上画出一个非正式的程序架构图，列出术语，进行分析。

敏捷团队建设刚写好的时候本来尝试发javaeye，结果那天好像服务器有问题没提交上来。这么多天才想起来重新发。。。

敏捷团队建设本文发表于4月《软件世界》

最近很多人都问我，有没有适合的人可以推荐给他们公司，他们正在招人，面试了很多个，但有经验的开发人员太难找了。有一个朋友在问我要人的同时，他手下的一个开发人员反而问我有没有好的机会，他想跳槽。

不久前一份报告称，中国本地软件企业面临的最大问题之一，就是高级技术人才的缺乏。造成这种问题的原因，主要是由于本地软件企业的人才培养机制和管理机制的欠缺。人才大量涌入外资企业和频繁的流动，导致了各类有经验人才的欠缺。

每个人都会梦想自己的理想工作。做技术的开发人员要求的更是简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。这些东西，很多时候就是一个人决定离职的因素。

有的公司认为开发团队是成本中心，所以给他们买最便宜的桌椅——而恰恰是开发人员们一天都依赖于这样的桌椅为公司创造价值；有的公司觉得自己的一套软件不停的实施就能不停盈利——而开发人员最厌烦的就是做重复性工作；有的公司要求开发人员必须上班打卡——好的，那开发人员绝对不会晚下班一分钟。有的公司从来不举行内部的技术交流和培训活动——而开发人员希望的技术提高绝不仅仅是只靠读书能够完成的。

公司要依靠软件来盈利。而要开发一个成功的软件项目，人的作用是第一位的。而个人的力量相对于整个团队来说，又是微不足道的。稍微有点规模项目的成功都是集体努力的结果，而不是靠一两个英雄程序员能够完成的。为了能够保持一个稳定和高效的团队，建设一个吸引开发人员的环境和氛围是所有公司的管理人员们应该考虑的一件事。一个核心的产品开发人员离职，很可能使得当前的项目或订单陷入瘫痪，这目前已经成为了影响许多中小公司存亡的大事。

我所在的公司不仅仅以敏捷过程著称，同时，它以其特有的文化和团队氛围吸引了一大批高水平的开发人员。他们不仅仅是认