qileilove

　　作为一个开发团队的管理者，例如当你是一个团队的项目经理的时候，任务的完成情况通常是你最关心的内容之一，比如说分配的任务是否能够按时间完成，整个项目的进度是否尚在计划之中，团队内的人是不是都在高效地工作，大家有没有什么困难，这些是你经常会关注的问题。在软件开发团队中，任务的分配、跟踪和管理通常是这个团队管理者的一个重要的工作内容。

　　1、从问题谈起

　　我曾经碰到过一个项目经理，她管理着一个团队开发一个web应用，团队里开发人员大概10个左右，测试人 员3个，业务分析师1个人。对于任务的管理她是这么做的。通常，她会将需求分析人员分析得到的需求给每个人分一些。然后每个人在领到任务之后会给她承诺一 个大致的时间点。整个项目大致的交付计划用一个excel表管理着，根据客户要求的交付时间点，并且考虑到一些需求之间的集成测试关系，定出了每个需求的 大致交付时间点。只要每个开发人员承诺的时间点和期望的相差不大，她都可以接受，每个开发人员这样就知道自己应该在什么时间点交付什么东西。

　 　一切本该很完美，但是不和谐的问题不断出现。最经常发生的事情就是大家在承诺的时间点快要到的时候不能按时交付，每次她询问进度的时候，会被告知还差一 点就完成了。通常的说法是“底层部分已经做完了，或还差页面部分就可以搞定了”，然而实际情况是又过了相当的时间才真正完成。当然也不是没有按时交付的需 求，但是她发现也许是大家经常加班，已经开始疲倦了，有时候明明很简单的可以提前完成的需求，大家还是到最后一刻才交付给测试。

　　也有的 开发人员拿到自己的那一批需求之后，会批量工作，把若干个类似的需求的底层逻辑全部实现，然后再实现上层内容。她默认了这种做法，就像这位开发人员说的 “这几个需求都差不多，只要底层做好了，基本上就都差不多完成了”。虽然这部分工作早点和其他人一起集成测试会比较好，但是他这样做也只能推后集成测试的 时间点了。还好承诺给测试团队的交付时间点还在1个月之后，只要1个月之内能够完成这些需求就可以了。

　　还有一些其他的问题，比如有的新 人经常碰到问题，然而出了问题并不会主动问其他人，而是在胡乱尝试中浪费了时间。组里还有个开发人员非常激进，经常花时间去重构代码，追求完美的架构设 计，进度很让人担忧。组内的开发人员有时候还经常被其他项目的事情打扰，因为有几个人刚刚从上一个项目中调过来，上个项目的有些问题只有他们熟悉和有能力 解决。她就不止一次发现，有一个开发人员经常在修复其他项目的bug。

　　她会不定时地去询问每个开发人员的开发进度，当需求的计划交付时 间点逼近的时候，这种检查会越来越频繁，开发人员感受到压力，有时候甚至需要加班来完成开发工作。然而尽管她花了很多精力去跟踪和检查每个需求的完成情 况，还是有很多出乎期望的事情在不断发生。尽管她一直相信说，只要开发人员们能够完成任务，采用什么方式她是不干预的，而具体的时间也是由他们自己分配 的。但是她渐渐感觉到，任务越来越不可控，计划通常无法按时完成，每天对大家的检查花了大部分时间，然而却不能揭示出真正的问题。

　　运转 良好的项目都差不多，而问题项目的问题各有各的不同。尽管每个团队的问题可能不完全相同，但是当我们审视这些项目的运作和管理方式的时候，不难发现一些诸 如多任务并行等共性的问题，这些问题给软件项目带来了各种各样的浪费。当一个团队采用瀑布开发模式的时候，开发阶段全部结束之后测试人员才会介入，开展测 试活动，在一个通常很漫长的开发阶段内，各种开发活动中的浪费、估计的不准确，以及成员自己的拖沓、被打扰、问题阻塞等，都被掩盖住了。只要在最终时间点 前能够全部开发完成，不管是前松后紧，还是加班熬夜，都已经成了项目开发的常态。项目经理只能看到交付的最终时间点，问题不能及时的暴露，而等到问题被暴 露的时候，可以使用的调整手段也非常有限。

　　这样的一种团队生存状态在外部环境要求短交付周期，需求允许经常变化的情况下显示出了极度地 不适应。市场环境的变化驱动了软件需求的变化，这种变化催生了缩短交付周期的诉求，较短的交付周期使得人们可以不必去预期过于长远的需求，具备根据市场的 变化快速地制定和调整软件需求的能力。而当交付模型由几个月的瀑布模型转变为数周甚至更短的迭代模型的时候，我们在前面谈到的团队中的各种浪费、低效、半 成品堆积等问题，就会急剧地爆发出来。

　　熟悉敏捷方 法的读者可能都知道，敏捷方法包含一系列实践来帮助团队实现短周期快速交付，更好地响应需求变化。比如说userstory方法，将需求从用户价值的角度 进行组织，避免将需求从功能模块角度划分。小粒度的用户故事可以在一两周的迭代内完成开发和测试（并行开发），从而可以缩短交付周期。问题是，在敏捷团队 内，我们是如何有效管理大量小粒度userstory，同时避免上述项目管理中的问题呢？下面我们结合敏捷开发中的看板工具来看看敏捷团队是如何管理任务的。

　　2、可视化看板任务管理

　　看板源于精益生产实践，敏捷将其背后的可视化管理理念借鉴过来，经过一番改造，形成了有自己独特风格的可视化管理工具。曾有人总结过scrum和kanban的使用，而很多时候，我们也将它叫做迭代状态墙。

　　先看看我们怎么样能用这个状态墙来管理迭代任务。说起来其实是一个很简单的东西。

　　通常一个迭代的状态墙上反映了某一个迭代的计划和任务进展情况。状态墙上按照一个迭代内团队的典型开发活动分成几栏，例如“待开发”、“开发 中”、“待测试”、“测试中”、“测试完成”等。在一个迭代之初，我们会将计划在本迭代完成的故事卡放到“待开发”这一栏中。可视化状态墙的一个好处就是 所有团队成员都可以实时地了解到本迭代的计划和进展情况。开发人员领取任务时，就将他领取的故事卡片从“待开发”移到“开发中”，同时贴上带有自己名字的 小纸条。当他开发完成之后，就将故事卡片移到“待测试”一栏。我们的测试人员看到这一栏里有待测的故事卡时，就取下一张，移动到“测试中”，开始这个用户 故事的测试，测试完成后，就将故事卡移动到“测试完成”一栏。如果测试人员发现了一个bug，那么他可以用红颜色的卡片记下这个bug，然后放到待开发这 一栏中。在状态墙上，除了用户故事、bug之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这三类任务用不同颜色的卡片，放到状 态墙上统一管理。

　　这样一个简单的工具，是如何帮助我们消除浪费、解决项目管理中的问题的？让我们逐条分析一下看看。

　　2.1 如何减少返工带来的浪费

　　返工是软件开发过程中的一大严重浪费。比如说开发人员开发完成的任务交给测试人员测试的时候，关键流程不能走通，阻碍了测试进程；交付给客户的 东西被客户说“这不是我想要的东西”；分析人员将还没分析透彻的任务交给开发人员，在最后验收的时候发现开发人员加入了自己的一些“发挥”。这些都会造成 返工。返工意味着没有一次性将事情做对，意味着流程中的上游没有交付高质量的工作，也可能意味着团队成员间的沟通出了问题。

　　在传统的瀑布流程中，我们往往是期望通过前期细致入微的工作来确保一个阶段的工作被高质量完成之后才移交到下一阶段。后来我们慢慢从失败的经验 中学习到，这种方法在变化的需求环境下实在是太过脆弱，不仅不能如愿保证质量，而且会造成更大的浪费，交付周期也不能满足要求。于是我们引入了迭代式开发 方法，一个需求的分析、开发、测试、验收成了一个小粒度地更连续的过程，在这个小的交付循环中，看板帮助我们以更细节的粒度来管理一个任务每个阶段的工作 质量。

　　通常我们是这么做的。当我们把一张故事卡从“待开发”移动到“开发中”时，这张卡片必须是已经分析完成的。也就是说，当开发人员准备真正开始开 发这张故事卡之前，我们的需求分析师们必须保证这张卡片所包含的所有内容和细节已经被分析完成，不再有模棱两可的细节，不再留给开发人员过多的自我发挥和 想象空间，而且这些细节必须和客户确认过，而不只是团队自己“设计”的结果。

　　这一道关看似很寻常，实际上很多项目会在这里出问题。很多时候开发人员开始开发的时候，需求还没有分析完成，很多细节尚须澄清确认，实现上的技 术风险还没有被完全排除。也有的分析师善于给开发人员留有大量自我发挥空间，需求过于言简意赅。开发人员开始开发这样的需求时，要么做不下去，要么按照自 己的理解做下去。做完了之后分析师一看发现不对，和我想的不一样，于是开发人员返工。最糟糕的情形莫过于最后被客户发现说，这不是我当初想要的东西。

　　由此可见，确保开发人员挪卡的时候，这张待开发的用户故事已经被真正分析完成，是我们准确实现用户需求的第一步。通过规定这一挪卡的前提，同时 辅以用户故事的澄清（由分析师向开发人员澄清）或者反向澄清（由开发人员向分析师讲述自己的理解），可以很大程度上将返工减少到最低。

　　还有一种浪费发生在测试过程中。测试人员经常会发现，处于“待测试”状态中的一些故事卡，在测试的时候主要的流程都走不通，根本无法进一步展开测试，于是乎不得不将故事卡

　　打回到开发人员手中。而往往这个时候开发人员已经工作在另一个用户故事上了。要么他停下手中的任务解决测试的问题，要么让测试人员等到这些问题修复过后再测。无论哪种都是不好的选择。

　　这种问题的一个主要原因是因为开发人员声称他已经“开发完成”，将故事卡从“开发中”挪到“待测试”时，实际上自己并没有对这部分功能进行测 试。或者是因为疏忽，或者是因为懒惰，或者是因为过于自信。通过在这个状态转换阶段引入用户故事初验，让分析师在挪卡之前先到开发人员机器上看看是否该故 事卡包含的功能被实现了，可以很大程度上提升效率，减少浪费。若分析师在初验过程中发现了问题，那么开发人员马上能以最小的成本进行修复，而不用等到之后 测试人员发现时再来修复。而且，分析师初验也提供了一个判断实现是否良好的反馈点，这是我们能够看到一个需求是否被实现并能够真正工作的最早的时间点。

　　2.2 如何避免多任务并行

　　多任务之间的频繁切换是一个常见的问题。表现在团队里的成员，特别是开发人员，会在不同的任务间切换。就像前面的故事中提到的，可能这一刻还在 实现某一个需求，而下一刻马上就会被叫走去修复某一个遗留版本的缺陷。又或者该人手头被分配了多个任务，每个任务都在进行中，而没有一个处于完成状态。任 务切换是导致效率降低的一个重要原因，不同任务间的上下文的切换会导致频繁地将任务当前状态在头脑中“压栈”和“出栈”，这些操作会耗费时间。如果完成一 个任务需要一个人一天时间，那么两天内这个人可以完成两个任务，但是如果他在第一天同时开始并行工作在这两个任务上，那么完成这两个任务会需要大于两天的 时间。

　　大家可能已经注意到了，在前面的看板图中，处于“开发中”的所有任务卡片上都有一个小纸条，上面标记着正在这张卡片上工作的人的名字。如果说有 两个人结对在一个卡片上工作，那么这张卡片上应该有两个名字。这一小小的实践可以帮助我们随时发现团队内某一时刻，是否每个人只工作在一个任务上。

　　我们在领取“待开发”状态栏中的卡片时，保证每次每人只领一张卡片，不要多领，完成了这张卡片之后，再回来领下一张。当一张卡片被认领之后，我 们就会对这张卡片进行跟踪，在站会上谈论它的完成情况，谈论实现过程中碰到的问题。当它的进度和估计的可能偏差较大时，我们能够及时而不是在最后一刻察觉 到，提供需要的帮助，确保它能够顺利完成。这样一种方式让我们能够将注意力集中到小粒度的需求（例如用户故事）上，更多地关注这些用户故事的流动速度。而 当每个小的用户故事能够顺畅地流动起来时，整个项目的交付也得到了保障。

　　当然这一实践并不能自动保证团队内不再出现多任务并发、拖延、或者做和任务无关的其他事情等问题。可能有些人在做一个用户故事的过程中，突然中断去做了一些其他事情，但是

　　却没有及时在状态墙上更新自己的状态。重要的是团队要有实现交付目标的共同愿景，能够透明地暴露问题，并且善于利用状态墙来发现和改进自身的问题。对于不成熟的团队，这可能需要一个转变的周期。

　　如果一个团队的职责共享较好，代码被所有人集体拥有，每个人都被鼓励熟悉和工作在代码的不同部分，那么在这样的团队内便不太会出现把一大块任务 事先就明确给某一个人的情况。相反，所有人的工作事先不具体确定，大家会更容易形成某一时刻只领取一张卡片的情况，避免同时工作在多个任务上。实际上，状 态墙的使用也可以帮助团队走向职责共享之路，只需要在大家领取任务的时候有意地给人们分配一些之前没做过的内容，同时安排好有经验的人与其结对工作，一段 时间之后，团队内的人便会逐渐体会到和之前只是专注在一个模块内不同的工作方式。

　　2.3 如何减少半成品库存，缩短交付周期

　　一个需求的交付周期（leadtime）是从它被识别到最终交付给用户手中所耗费的时间。交付周期越短，意味着客户从提出想法到能够在软件中实 际使用到这个点子的时间越短。从客户的角度来看，更短的交付周期意味着自己的软件能够对市场变化的更快地响应，因而获得更强的竞争力，同时也意味着能够更 快地验证自己的想法。

　　任务管理的粒度太大会直接导致交付周期变长。最极端的情况是将属于某一模块的任务在一开始就全部分给负责这个模块的人，所有这个模块相关的修改 都由他来实现。在一个按模块划分职责，每个人只负责自己具体模块的团队里，通常这个模块的负责人会实现这个模块的所有修改。不然，就是将一个可能需要做2 周到一个月的任务分给某个人。或者更好一点的情况是，单个任务本身不大，但是会将相关联的任务成批地分配给某个人。如果你的团队内也是采用大篇的“规格说 明书”等word文档来组织需求的，那么就要小心，这种问题很可能在团队内已经存在。整个团队没有小粒度频繁交付的概念，习惯了大批量长时间地交付方式。 由于批量大，所以估计常常不准，而且时间跨度长，中间也会有更多地干扰因素出现，这些都导致任务不能在开始承诺的时间点交付。开发周期长同样导致测试活动 的滞后，极端地滞后就演变为所有开发工作完成之后才能进行测试，这就是我们熟悉的瀑布模式。最终的影响就是需求的交付周期会很长。

　　传统团队的一个常见组织方式是按照功能模块划分团队成员，明确分离职责，这也会变相增长交付周期。这样的团队通常倾向于按照功能模块来组织半成 品任务，而不是按照可以交付价值的完成品来组织任务。习惯按照功能模块来组织开发的团队通常会阶段性得“联调”，不同模块的人带着自己的代码合在一起调 试，由于缺乏频繁地集成，这种联调活动的时间经常不可控。团队在大部分时间内通常只拥有一大堆半成品，后续的测试和验收活动没有办法进行，而只能等到团队 在某一刻组装出一个完整的功能后才能测试，因此交付周期也会比较长。

　　因此，如果我们的需求都是按照软件的功能模块划分，而不是按照面向用户的价值来划分的，那么我们在交付用户价值这一目标上，一开始就走错了路。采用用户故事能够把需求以用户能够理解的价值来组织，这一点是我们缩短交付周期的一个重要基础。

　　我们的状态墙能够揭示需求的交付周期。让我们来看看这样几个场景。

　　如果我们的需求是按照软件的功能模块划分的，那么通常单个模块的编码完成往往不可测。例如有的团队喜欢将web应用的上层页面部分和下层数据库 逻辑部分划分到不同的模块组，一个用户的需求也会拦腰切成两截，一部分交给上层团队完成，一部分交给下层团队。单个团队的任务完成都不能开展这个需求的测 试，于是这些任务就会堆积在“待测试”这一栏。

　　如果我们的需求很大，以至于开发人员要花费很长的时间（超过1周）才能完成开发，那么这个需求会在“开发中”这一栏停留很久。大家可以猜到，当一个人同时进行多个任务时，这些任务也会比它们单个依次被开发时在“开发中”这一栏停留更久的时间。

　　任何一栏中的任务其实都是半成品，只有完成测试，交付到用户手中的需求才是完成品。状态墙上的每一栏都好比一个存放着各种零件的仓库，每一栏中 的卡片越多，停留的越久，就说明当前半成品的库存越多，是该得到团队的认真关注的时候了。状态墙将每个阶段的半成品数量可视化呈现出来，让虚拟的数量通过 卡片这种物理介质的数量得以呈现。

　　通过状态墙，我们可以计算出每一个需求的交付周期大概是多久。状态墙上一个用户故事从放到“待开发”这一栏，到它被移动到“完成”这一栏，这一 个时间段是需求的整个交付周期的其中一段，也是很重要的一段。通过优化从“待开发”到“完成”的这一个过程，我们可以缩短需求的交付周期。通过比较需求的 交付周期和客户对交付周期的要求，我们可以量化之间的差距，然后指导我们的改进。

　　在我们理解了状态墙是如何呈现一个需求的交付周期后，我们就不难理解瀑布方法是如何让交付周期变长的。在瀑布模型中，全部开发完成之后才会进行 测试工作，相当于所有的任务卡片都堆积到“待测试”状态之后，才开始逐一测试。所有开发完成的半成品，都会留存在“待测试”这一仓库中，一直等到所有开发 活动结束的那一刻。

　　当出现库存堆积的时候，就是我们需要改进的时候。如果“待测试”这一栏有太多的任务卡片，那么就说明我们的测试活动没有跟上。有可能是我们的测 试环境出了问题，或者是我们的测试人员人力不足。如果太多的卡片位于“测试完成”状态，说明我们的发布和最终交付过程出了某些问题。如果“待开发”这一栏 中任务过多，说明我们的计划有可能超出了当前团队的开发能力，或者说反映了开发人员的不足。也有一种情况，那就是“待开发”这一栏空了很久，这可能说明了 另外一个问题，那就是我们的分析师的分析速度匹配不上团队的开发能力。一个良好的团队，必然是各种角色协调配合，并行工作，同时他们之间的任务衔接也能够 比较流畅。

　　2.4 迭代产能的度量，计划及其他

　　团队在每个迭代所能完成的工作量，通常被成为迭代的velocity（速度），是衡量团队每迭代产能的一个指标。这个指标能够帮助团队进行制定 迭代计划。根据团队估计任务工作量的方法不同，迭代的velocity的单位也可能不同（例如故事点数）。通常，我们只需要在迭代结束的时候，数一数状态 墙上完成的任务工作量就可以了。

　　当我们经历了若干个迭代以后，通常团队的迭代速度会趋于稳定，我们在做下一个迭代的计划的时候，会参考以往迭代的数据。如果上个迭代完成了15个点，那么下个迭代我们通常也

　　会计划15个点左右的工作量，将这些卡片放到“待开发”这一栏中。也就是说，每个迭代结束时，我们都会对状态墙进行更新，将即将到来的迭代的卡片放到墙上，并且将一些处于半成品状态的卡片进行适当的调整。

　　前面提到，状态墙上可能由三种卡片，除了需求，还可能有bug和技术任务。测试人员每次在迭代中测出一个bug，就会将bug写成卡片，放到 “待开发”这一栏。当bug不多的时候，团队可以在不太影响原有计划的情况消化掉这些bug，确保软件的质量持续地得到保证。如果bug太多，则需要做一 些计划，将bug分散到几个迭代里去消化。然而到这个时候，团队可能更需要及时反省一下为什么会出现这么多bug的原因了。

　　另一类技术任务也需要和bug以及需求卡片一起被考虑到迭代计划中去。通常技术任务包括诸如搭建持续集成环境、准备测试环境、重构这样的任务。 它们虽然不直接给用户带来价值，但是却是保证软件质量、确保团队效率的重要因素。比如重构类的任务，对于工作在遗留系统上的团队来说可能是需要一直考虑的 事情，为了保障新的需求的顺利实现，可能需要有计划地重构之前的一些遗留代码。

　　bug和技术任务耗费团队成员的时间资源，但是不直接产生用户价值。如果我们衡量团队每个迭代的总体生产能力，需要在计算迭代速度时考虑这三类 任务。但是如果我们只考察团队每迭代交付的用户价值的量的大小，那么就不应该包含技术任务和bug。当一个团队在迭代中花了过多的时间在技术任务上，或者 修复bug上，那么团队就需要回顾反省一下其中的原因，是否是团队的基础设施太差，或者是团队在开发时过于粗心导致太多的bug，抑或是其他的一些原因。

　　3、总结

　　在本文中我们从项目管理中常常出现的一些问题着手，分析了其中的一些原因，然后介绍了如何采用状态墙（看板）来可视化任务管理。在敏捷项目中， 状态墙作为一种有效的迭代任务管理工具，已经被广泛地使用。团队利用状态墙这样一种简单的工具，将迭代开发中的日常工作透明实时地跟踪管理起来，能够帮助 团队及时发现问题，消除浪费，快速地交付用户价值。希望这些文字，能够对渴望尝试敏捷、改善任务管理和日常运作的团队带来一些帮助。

　　优化目标

　　1、减少 IO 次数

　　IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，当然，也是收效最明显的优化手段。

　　2、降低 CPU 计算

　 　除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。order by， group by，distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们 SQL 优化的重要目标

　　优化方法

　　1、改变 SQL 执行计划

　 　明确了优化目标之后，我们需要确定达到我们目标的方法。对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标

　　常见误区

　　1、count(1)和count(primary_key) 优于 count(*)

　 　很多人为了统计记录条数，就使用 count(1) 和 count(primary_key) 而不是 count(*) ，他们认为这样性能更好，其实这是一个误区。对于有些场景，这样做可能性能会更差，应为数据库对 count(*) 计数操作做了一些特别的优化。

　　2、count(column) 和 count(*) 是一样的

　　这个误区甚至在很多的资深工程师或者是 DBA 中都普遍存在，很多人都会认为这是理所当然的。实际上，count(column) 和 count(*) 是一个完全不一样的操作，所代表的意义也完全不一样。

　　count(column) 是表示结果集中有多少个column字段不为空的记录；

　　count(*) 是表示整个结果集有多少条记录；

　　3、select a，b from … 比 select a，b，c from … 可以让数据库访问更少的数据量

　　这个误区主要存在于大量的开发人员中，主要原因是对数据库的存储原理不是太了解。

　 　实际上，大多数关系型数据库都是按照行(row)的方式存储，而数据存取操作都是以一个固定大小的IO单元(被称作 block 或者 page)为单位，一般为4KB，8KB… 大多数时候，每个IO单元中存储了多行，每行都是存储了该行的所有字段(lob等特殊类型字段除外)。

　　所以，我们是取一个字段还是多个字段，实际上数据库在表中需要访问的数据量其实是一样的。

　　当然，也有例外情况，那就是我们的这个查询在索引中就可以完成，也就是说当只取 a，b两个字段的时候，不需要回表，而c这个字段不在使用的索引中，需要回表取得其数据。在这样的情况下，二者的IO量会有较大差异。

　　4、order by 一定需要排序操作

　　我们知道索引数据实际上是有序的，如果我们的需要的数据和某个索引的顺序一致，而且我们的查询又通过这个索引来执行，那么数据库一般会省略排序操作，而直接将数据返回，因为数据库知道数据已经满足我们的排序需求了。

　　实际上，利用索引来优化有排序需求的 SQL，是一个非常重要的优化手段

　　5、执行计划中有 filesort 就会进行磁盘文件排序

　　有这个误区其实并不能怪我们，而是因为 MySQL 开发者在用词方面的问题。filesort 是我们在使用 explain 命令查看一条 SQL 的执行计划的时候可能会看到在 “Extra” 一列显示的信息。

　　实际上，只要一条 SQL 语句需要进行排序操作，都会显示“Using filesort”，这并不表示就会有文件排序操作。

　　一、如何创建java存储过程？

　　通常有三种方法来创建java存储过程。

　　1、使用oracle的sql语句来创建：

　　e.g. 使用create or replace and compile java source named "<name>" as

　　后边跟上java源程序。要求类的方法必须是public static的，才能用于存储过程。

　　2、使用外部class文件来装载创建

　　e.g. 这里既然用到了外部文件，必然要将class文件放到oracle Server的某一目录下边。

1. public class OracleJavaProc  
2. {  
3.     public static void main(String[] argv)  
4.     {  
5.         System.out.println("It's a Java Oracle procedure.");  
6.     }  
7. }  
8. 
   
9. 
   
10. SQL> grant create any directory to scott;  
11. 
    
12. 授权成功。  
13. 
    
14. SQL> conn scott/tiger@iihero.oracledb  
15. 已连接。  
16. SQL> create or   replace   directory   test_dir   as  'd:/oracle';  
17. 
    
18. 目录已创建。  
19. 
    
20. SQL> create or replace java class using bfile(test_dir, 'OracleJavaProc.CLASS')  
21.   2  /  
22. 
    
23. Java 已创建。  
24. 
    
25. SQL> create or replace procedure testjavaproc as language java name 'OracleJavaProc.main(java.lang.String[])';  
26.   2  /  
27. 
    
28. 过程已创建。  
29. 
    
30. SQL> call testjavaproc();  
31. 
    
32. 调用完成。  
33. 
    
34. SQL> execute testjavaproc;  
35. 
    
36. PL/SQL 过程已成功完成。  
37. 
    
38. SQL> set serveroutput on size 5000  
39. SQL> call dbms_java.set_output(5000);  
40. 
    
41. 调用完成。  
42. 
    
43. SQL> execute testjavaproc;  
44. It's a Java Oracle procedure.

　　3、我推荐的一种方法，直接使用loadjava命令远程装载并创建。

　　先创建一个类, e.g.

　　使用loadjava命令将其装载到服务器端并编译：

　　查询一下状态：

　　测试一下存储过程：

1. SQL> create or replace procedure add_salgrade(id number, losal number, hisal num  
2. ber) as language java name 'OracleJavaProc.addSalGrade(int, int, int)';  
3.   2  /  
4.  
5. 过程已创建。  
6.  
7. SQL> set serveroutput on size 2000  
8. SQL> call dbms_java.set_output(2000);  
9.  
10. 调用完成。  
11.  
12. SQL> execute add_salgrade(6, 10000, 15000);  
13. Creating new salgrade for EMPLOYEE...  
14.  
15. PL/SQL 过程已成功完成。  
16.  
17. SQL> select * from salgrade where grade=6;  
18.  
19.      GRADE      LOSAL      HISAL  
20. ---------- ---------- ----------  
21.          6      10000      15000

　　二、如何更新你已经编写的java存储过程？

　　假如要往类OracleJavaProc里添加一个存储过程方法，如何开发？

　　正确的步骤应该是先dropjava, 改程序，再loadjava。

　　e.g.修改OracleJavaProc类内容如下：

1. import java.sql.*;  
2. import oracle.jdbc.*;  
3.  
4. public class OracleJavaProc {  
5.  
6.    // Add a salgrade to the database.  
7.    public static void addSalGrade(int grade, int losal, int hisal) {  
8.  
9.       System.out.println("Creating new salgrade for EMPLOYEE...");  
10.  
11.       try {  
12.          Connection conn =  
13.             DriverManager.getConnection("jdbc:default:connection:");  
14.  
15.          String sql =  
16.             "INSERT INTO salgrade " +  
17.             "(GRADE,LOSAL,HISAL) " +  
18.             "VALUES(?,?,?)";  
19.          PreparedStatement pstmt = conn.prepareStatement(sql);  
20.          pstmt.setInt(1,grade);  
21.          pstmt.setInt(2,losal);  
22.          pstmt.setInt(3,hisal);  
23.          pstmt.executeUpdate();  
24.          pstmt.close();  
25.          }  
26.       catch(SQLException e) {  
27.          System.err.println("ERROR! Adding Salgrade: "   
28.            + e.getMessage());  
29.          }  
30.    }  
31.      
32.    public static int getHiSal(int grade)  
33.    {  
34.     try {  
35.         Connection conn =  
36.           DriverManager.getConnection("jdbc:default:connection:");  
37.         String sql = "SELECT hisal FROM salgrade WHERE grade = ?";  
38.         PreparedStatement pstmt = conn.prepareStatement(sql);pstmt.setInt(1, grade);  
39.         ResultSet rset = pstmt.executeQuery();  
40.         int res = 0;  
41.         if (rset.next())  
42.         {  
43.             res = rset.getInt(1);  
44.         }  
45.         rset.close();  
46.         return res;  
47.        }  
48.     catch (SQLException e)   
49.     {  
50.         System.err.println("ERROR! Querying Salgrade: "   
51.            + e.getMessage());  
52.           return -1;  
53.     }      
54.    }  
55.         
56. }

　　如何更新呢？

　　后边的应用示例：

　　全文完！

　　用法个人见解：不要手动drop java source，不要手动drop procedure。

　　内部类：定义在类的内部的类

　　为什么需要内部类？

　　● 典型的情况是，内部类继承自某个类或实现某个接口，内部类的代码操作创建其的外围类的对象。所以你可以认为内部类提供了某种进入其外围类的窗口。

　　● java中的内部类和接口加在一起，可以实现多继承。

　　● 可以使某些编码根简洁。

　　● 隐藏你不想让别人知道的操作。

　　使用内部类最吸引人的原因是：

　 　每个内部类都能独立地继承自一个（接口的）实现，所以无论外围类是否已经继承了某个（接口的）实现，对于内部类都没有影响。如果没有内部类提供的可以继 承多个具体的或抽象的类的能力，一些设计与编程问题就很难解决。从这个角度看，内部类使得多重继承的解决方案变得完整。接口解决了部分问题，而内部类有效 地实现了“多重继承”。

　　内部类分为： 成员内部类、静态嵌套类、方法内部类、匿名内部类。

　　特点：

　　一、内部类仍然是一个独立的类，在编译之后内部类会被编译成独立的.class文件，但是前面冠以外部类的类命和$符号。

　　二、内部类可以直接或利用引用访问外部类的属性和方法，包括私有属性和方法（但静态内部类不能访问外部类的非静态成员变量和方法）。内部类所访问的外部属性的值由构造时的外部类对象决定。

　　三、而外部类要访问内部类的成员，则只能通过引用的方式进行，可问内部类所有成员

　　四、访问机制：

　　五、内部类可以使用任意的范围限定：public/private/protected class InnerClass，且严格按照这几种访问权限来控制内部类能使用的范围。普通类的范围限定只可以是public或者不加。

　　六、内部类的命名不允许与外部类 重名，内部类可以继承同级的内部类，也可继承其它类（除内部类和外部类）。

　　七、内部类可以定义为接口，并且可以定义另外一个类来实现它

　　八、内部类可以定义为抽象类，可以定义另外一个内部类继承它

　　九、内部类使用static修饰，自动升级为顶级类，外部类不可以用static修饰，用OuterClass.InnerClass inner=new OuterClass.InnerClass()；创建实例。内部类还可定义为final.

　　十、内部类可以再定义内部类（基本不用）

　　十一、方法内的内部类：

　　方法内的内部类不能加范围限定（protected public private）

　　方法内的内部类不能加static修饰符

　　方法内的内部类只能在方法内构建其实例

　　方法内的内部类如果访问方法局部变量，则此局部变量必须使用final修饰

　　1）静态内部类（静态嵌套类）

　　从技术上讲，静态嵌套类不属于内部类。因为内部类与外部类共享一种特殊关系，更确切地说是对实例的共享关系。而静态嵌套类则没有上述关系。它只是位置在另一个类的内部，因此也被称为顶级嵌套类。

　　静态的含义是该内部类可以像其他静态成员一样，没有外部类对象时，也能够访问它。静态嵌套类不能访问外部类的成员和方法。

　　引子

　　按照原定计划，今天开始研究 JMeter，一天的时间看完了大半的 User Manual，发现原来只要沉住气，学习效率还是蛮高的，而且大堆的英文文档也没有那么可怕。

　　本来想顺便把文档翻译一下，不过后来想了想，看懂是一回事，全部翻译出来又是另外一回事了，工作量太大，而且这也不是我一开始要研究 JMeter 的本意。不如大家有兴趣一起研究的遇到问题再一起讨论吧。

　　开源工具通常都是为了某个特定的目的而开发出来的，所以如果想找到一个开源的性能测试工具去与LoadRunner 或者 QALoad 之类去比较，实在有些勉强。但是开源工具也有它自己的优势：小巧、轻便，在自己擅长的领域可以提供优秀的解决方案。所以，我们可以考虑准备一个自己的“开 源测试工具箱”，平时利用空闲时间了解各种工具所适用的环境和目的，知识慢慢积累下来以后，就可以在遇到问题时顺手拈来，轻松化解。

　　另外，如果8月份和9月份的空闲时间足够多，我想我会写一个系列文章来讲述在实际的开发和测试过程中引入开源性能测试工具的情况。如果有朋友感兴趣，希望大家可以一起研究和讨论。

　　简介

　　ab的全称是ApacheBench，是 Apache 附带的一个小工具，专门用于 HTTP Server 的benchmark testing，可以同时模拟多个并发请求。前段时间看到公司的开发人员也在用它作一些测试，看起来也不错，很简单，也很容易使用。

　　通过下面的一个简单的例子和注释，相信大家可以更容易理解这个工具的使用。

　　一个简单的例子

　　在这个例子的一开始，我执行了这样一个命令 ab -n 10 -c 10 http://www.google.com/

　　这个命令的意思是启动 ab ，模拟10个用户(-n 10)同时访问 www.google.com ，并迭代10次(-c 10)。跟着下面的是 ab 输出的测试报告，红色部分是我添加的注释。

　　在这个例子的一开始，我执行了这样一个命令 ab -n 10 -c 10http://www.google.com/

　　这个命令的意思是启动 ab ，模拟10个用户(-n 10)同时访问www.google.com，并迭代10次(-c 10)。跟着下面的是 ab 输出的测试报告，红色部分是我添加的注释。

　　ab 不像 LR 那么强大，但是它足够轻便，如果只是在开发过程中想检查一下某个模块的响应情况，或者做一些场景比较简单的测试，ab 还是一个不错的选择——至少不用花费很多时间去学习 LR 那些复杂的功能，就更别说那 License 的价格了。

　　下面是 ab 的详细参数解释。

ab [ -A auth-username:password ] [ -c concurrency ] [ -C cookie-name=value ] [ -d ] [ -e csv-file ] [ -g gnuplot-file ] [ -h ] [ -H custom-header ] [ -i ] [ -k ] [ -n requests ] [ -p POST-file ] [ -P proxy-auth-username:password ] [ -q ] [ -s ] [ -S ] [ -t timelimit ] [ -T content-type ] [ -v verbosity] [ -V ] [ -w ] [ -x <table>-attributes ] [ -X proxy[:port] ] [ -y <tr>-attributes ] [ -z <td>-attributes ] [http://]hostname[:port]/path

-A auth-username:password

Supply BASIC Authentication credentials to the server. The username and password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the server needs it (i.e., has sent an 401 authentication needed).

-c concurrency

Number of multiple requests to perform at a time. Default is one request at a time.

-C cookie-name=value

Add a Cookie: line to the request. The argument is typically in the form of a name=value pair. This field is repeatable.

-d

Do not display the "percentage served within XX [ms] table". (legacy support).

-e csv-file

Write a Comma separated value (CSV) file which contains for each percentage (from 1% to 100%) the time (in milliseconds) it took to serve that percentage of the requests. This is usually more useful than the 'gnuplot' file; as the results are already 'binned'.

-g gnuplot-file

Write all measured values out as a 'gnuplot' or TSV (Tab separate values) file. This file can easily be imported into packages like Gnuplot, IDL, Mathematica, Igor or even Excel. The labels are on the first line of the file.

-h

Display usage information.

-H custom-header

Append extra headers to the request. The argument is typically in the form of a valid header line, containing a colon-separated field-value pair (i.e., "Accept-Encoding: zip/zop;8bit").

-i

Do HEAD requests instead of GET.

-k

Enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive.

-n requests

Number of requests to perform for the benchmarking session. The default is to just perform a single request which usually leads to non-representative benchmarking results.

-p POST-file

File containing data to POST.

-P proxy-auth-username:password

Supply BASIC Authentication credentials to a proxy en-route. The username and password are separated by a single : and sent on the wire base64 encoded. The string is sent regardless of whether the proxy needs it (i.e., has sent an 407 proxy authentication needed).

-q

When processing more than 150 requests, ab outputs a progress count on stderr every 10% or 100 requests or so. The -q flag will suppress these messages.

-s

　　搭建良好的测试环境是执行测试用例的前提，也是完成测试任务顺利完成的保证。测试环境大体可分为硬件环境和软件环境，硬件环境包括测试必须的PC机，服务器，设备，网线，分配器等硬件设备；软件环境包括数据库，操作系统，被测试软件，共存软件等；特殊条件下还要考虑网络环境，比如网络带宽，IP地址设置等。

　　搭建测试环境前后要注意以下几点：

　　1> 搭建测试环境前，确定测试目的

　　即是功能测试，稳定性测试，还是性能测试， 测试目的不同，搭建测试环境时应注意的点也不同。比如要进行功能测试，那么我们就不需要大量的数据，需要覆盖率高，测试数据要求尽量真实，这对硬件环境配 置的好坏要求不是太苛刻，为提高覆盖率，就要配置不同的硬件环境。如要进行性能测试，就需要大量的数据，测试数据应尽可能的达到符合实际的数据分配，这时 可能需要大量的设备来给测试对象施加压力，要提前准备大量设备。

　　2> 测试环境时尽可能的模拟真实环境

　 　这个要求对测试人员要求很高，因为很多测试人员没有去过用户使用现场，要完全模拟用户使用环境根本不可能。这时我们就应该通过技术支持人员，销售人员了 解，尽可能的模拟用户使用环境，选用合适的操作系统和软件平台，了解符合测试软件运行的最低要求及用户使用的硬件配置，了解用户常用的软件，避免所有配置 所有操作系统下都要进行测试，没有侧重点，浪费时间。这样一方面，可以在测试执行过程中发生软件产品与其他协同工作产 品之间的兼容性，避免软件发布给用户之后才发现的问题；另一方面也可以用来检验产品是不是用户真正需要的。多说情况下，测试环境都是真空环境，完全纯净的 平台，测试时，没有问题，一旦拿到现场，与其它软件并存，硬件配置等原因，问题多多，这个就是搭建测试环境时没有考虑用户的使用环境。

　　3> 确保无毒环境

　 　我测试过几个项目都是因为搭建的测试环境感染病毒，导致测试软件经常出现莫名的崩溃，运行不起来等现象，导致测试中断。这是杀毒是必要的，但是杀毒的时 间也应掌握好，具体可按照下列步骤：选择PC机-à安装操作系统—>安装杀毒软件杀毒—>安装驱动程序及用户常用软件及浏览器à杀毒à安装测 试软件—>杀毒，安装测试软件后杀毒，要注意如果我们不是使用正版杀毒软件，很可能我们安装的测试软件的一些文件被当做可疑文件或者病毒被清除，导 致测试软件直接不可用。要确保杀毒软件正版，如果不是正版，建议在安装测试软件前，卸载掉杀毒软件。测试过程中，要注意U盘的使用以及测试环境与外网的控 制。每次使用U盘前，要在其它机器上先杀毒；当测试环境与外网联通时，不建议使用共享方式互访测试机。当小范围PC机与外界隔离起来做测试环境时，可以禁 掉可移动存储设备的使用，只允许一台PC使用，这台PC机上安装杀毒软件，进行资料传送时，先拷贝到这台机器上杀毒，然后以共享的方式进行资料的传送。经 过这些措施可以很好的防止病毒感染测试环境，确保无毒环境。

　　4> 营造独立的测试环境

　 　测试过程中要确保我们的测试环境独立，避免测试环境被占用，影响测试进度及测试结果，比如设备连网后，是不是其他测试组也在共用，这样就可能影响我们的 测试结果。有时开发人员为确定问题会使用我们的测试环境，这样会打乱我们的测试活动，更严重的是影响测试进度。为避免这种情况，测试人员在提交缺陷单时， 提供详细的复现步骤以及尽可能多的信息。让开发人员根据缺陷单，在开发环境中复现和定位问题。

　　5> 构建可复用的测试环境

　 　当我们刚搭建好测试环境，安装测试软件之前及测试过程中，对操作系统及测试环境进行备份是必要的，这样一来可以为我们下轮测试时直接恢复测试环境，避免 重新搭建测试环境花费时间，二来在当测试环境遭到破坏时，可以恢复测试环境，避免测试数据丢失，重现问题。构建可“复用”的测试环境，往往要用到如 ghost、Drive Image等磁盘备份工具软件；这些工具软件，主要实现对磁盘文件的备份和还原功能；在应用这些工具软件之前，我们首先要做好以下几件十分必要的准备工 作：

　　A、确保所使用的磁盘备份工具软件本身的质量可靠性，建议使用正版软件；

　　B、利用有效的正版杀毒软件检测要备份的磁盘，保证测试环境中没有病毒

　　C、对于在测试过程中备份时，为减少镜像文件的体积，要删除掉Temp文件夹下的所有文件，要删除掉Win386.swp文件或_RESTORE文件夹，这样C盘就不至于过分膨胀，选择采用压缩方式进行镜像文件的创建，可使要备份的数据量大大减小；

　　D、最后，再进行一次彻底的磁盘碎片整理，将C盘调整到最优状态。

　　对于刚安装的操作系统，驱动程序等安装完成之后，测试程序安装之前，也要进行备份工作，这样可以防止不同项目交叉进行时，当使用相同操作系统时，直接恢复即可。

　　完成了这些准备工作，我们就可以用备份工具逐个逐个的来创建各种组合类型的软件测试环 境的磁盘镜像文件了。对已经创建好的各种镜像文件，要将它们设成系统、隐含、只读属性，这样一方面可以防止意外删除、感染病毒；另一方面可以避免在对磁盘 进行碎片整理时，频繁移动镜像文件的位置，从而可节约整理磁盘的时间；同时还要记录好每个镜像文件的适用范围，所备份的文件的信息等内容。

　　测试环境的搭建和维护处在重要的位置，它的好坏直接影响测试结果的真实性和准确性。维护测试环境需要大量的精力，不是一个人能完成的，需要我们大家积极配合。

　　需求获取可能是软件开发中 最困难、最关键、最易出错及最需要沟通交流的活动。对需求的获取往往有错误的认识：用户知道需求是什么，我们所要做的就是和他们交谈从他们那里得到需求， 只要问用户系统的目标特征，什么是要完成的，什么样的系统能适合商业需要就可以了，但是实际上需求获取并不是想象的这样简单，这条沟通之路布满了荆棘。首 先需求获取要定义问题范围，系统的边界往往是很难明确的，用户不了解技术实现的细节，这样造成了系统目标的混淆。

　　其次是对问题的理解，用户对计算机系统的能力和限制缺乏了解，任何一个系统都会有很多的用户或者不同类型的用户，每个用户只知道自己需要的系统，而不知道系统的整体情况，他们不知道系统作为一个整体怎么样工作效 率更好，也不太清楚那些工作可以交给软件完成，他们不清楚需求是什么，或者说如何以一种精确的方式来描述需求，他们需要开发人员的协助和指导，但是用户与 开发人员之间的交流很容易出现障碍，忽略了那些被认为是“很明确的信息。最后是需求的确认，因为需求的不稳定性往往随着时间的推移产生变动，使之难以确 认。为了克服以上的问题，必须有组织的执行需求的获取活动。

　　需求获取活动建议要完成的11个任务或者说步骤分别是确定需求过程、编写项 目视图和范围文档、用户群分类、选择用户代表、选择用户代表、建立核心队伍、确定使用实例、召开联合会议、分析用户工作流程、确定质量属性、检查问题报告 和需求重用。当然应该根据组织和项目的具体情况进行适当的裁减，比如根据项目和用户情况把需求获取会议改成问卷调查或者座谈等等。

　　1、编写项目视图和范围文档

　 　系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益，反映了组织机构或用户对系 统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予 以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。

　　非功能性需求是用户对系统良好运 作提出的期望，包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户需求，然后通过需求分析得到系统的功能 需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解决方案的商业和技术可行性，所有的使用 实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对项目的目标和范围能达成共识，整个项目 组都应该把注意力集中在项目目标和范围上。

　　2、用户群分类

　　系统用户在很多方面存 在着差异，例如：使用系统的频度和程度、应用领域和计算机系统知识、所使用的系统特性、所进行的业务过程、访问权限、地理上的布局以及个人的素质和喜好等 等。根据这些差异，你可以把这些不同的用户分成不同的用户类。与UML中Usecase的Actor概念一样，用户类不一定都指人，也可以包括其他应用系 统、接口或者硬件，这样做使得与系统边界外的接口也成为系统需求。将用户群分类并归纳各自特点，并详细描述出它们的个性特点及任务状况，将有助于需求的获 取和系统设计。

　　3、选择用户代表

　　不可能对所有的用户都进行需求获取，这样做时间 不允许效果也不一定好，所以要识别出能够确定需求和了解业务流程的用户作为每类用户的代表。每类用户至少选择一位能真正代表他们需求的人作为代表并且能够 作出决策，用户代表往往是本类用户中三类人：对项目有决定权的领导、熟悉业务流程的专家、系统最终用户。

　　每一个用户代表者代表了一个特定的用户类，并在那个用户类和开发者之间充当主要的接口，用户代表从他们所代表的用户类中收集需求信息，同时每个用户代表又负责协调他们所代表的用户在需求表达上的不一致性和不兼容性。

　　4、建立核心队伍

　 　通常用户和开发人员不自觉的都有一种”我们和他们“的想法，产生一种对立关系，把彼此放在对立面，每一方都定义自己的”边界“，只想自己的利益而忽略对 方的想法。他们通过文档、记录和对话来沟通，而不是作为一个合作的整体去识别和确定需求完成任务。实践证明这样的方法是不正确的，不会给双方带来一点益 处，良好的沟通关系没有建立导致了误解和忽略重要的信息。只有当双方参与者都明白要成功自己需要什么，同时也知道要成功对方需要什么时，才能建立起一种合 作关系。

　　为了建立合作关系通常采取一种组队的方式来获取需求，建立一个由用户代表和开发人员组成的联合小组作为需求获取的核心队伍。联 合小组将负责识别需求、分析解决方案和协商分歧，小组成员可以采用会议、电子邮件、综合办公系统等方式进行交流，但交流时应注意以下原则：小组会议应该由 中立方来组织和主持，用户和开发人员都要参加；交流预先要确定准备和参与的规则；议题要明确并覆盖所有关键点，但信息来源应该自由；交流目标要明确，并告 知所有的成员。

　　5、确定使用实例

　　从用户代表处收集他们将使用系统完成所需任务的 描述，讨论用户与系统间的交互方式和对话要求，这就是使用实例，一个单一的使用实例可能包括完成某项任务的许多逻辑相关任务和交互顺序。使用实例方法给需 求获取带来的好处来自于该方法是用以任务为中心和以用户为中心的观点，比起使用以功能为中心和以开发者为中心的方法，使用实例方法可以使用户更清楚地理解 和认识到新系统允许他们做什么和怎么做。描写使用实例的时候要注意使用简洁直白的表述，尽量使用主动语态，”系统“或者”用户“作为主语，比如”用户提交 用户密码，系统验证用户密码是否正确“，还有一点在描述中不要设计界面细节，比如”用户从下拉框中选择产品类型“。使用实例为以后写用例场景描述中的基本 路径和扩展路径提供了素材。

　　6、召开联合会议

　　最常见的需求获取方法是召开会议或者面谈，联合会议是范围广的、简便的讨论会，也是核心队伍成员之间一种很好的沟通方法，该会议通过紧密而集中 的讨论得以将用户代表与开发人员间的合作伙伴关系付诸于实践并能由此拟出需求文档的底稿。联合会议的第一个议题就是系统的必要性和合理性，必须所有成员都 同意系统是必要的而且合理的。接下来就可以讨论使用实例清单，清单可以打印成大纸挂在墙上、写在黑板上或做成演示材料。对每个清单合并去掉重复项，加上补 充内容就可以得到一份总的清单，注意避免采用负面的”太差“”不可行“去否定用户的想法，这些想法都应该保留下来作为被评议的清单项，这样保护了小组成员 开放的思维。最后对清单进行讨论，会议成员必须检查每一个使用实例，在把它们纳入需求之前决定其是否在项目所定义的范围内，形成最终的需求报告。

　　在进行讨论时，也应该避免受不成熟的细节的影响，在对系统需求取得共识之前，用户能很容易地在一个报表或对话框中列出某些精确设计，如果这些细 节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制，应确保用户参与者将注意力集中在与所讨论的话题适合的抽象层上，重点就是讨论做什么而不 是怎么做。这里有一点很重要就是要让用户理解对于某些功能的讨论并不意味着即将在系统中实现它，更不要做暗示或者承诺什么时候完成需求。在讨论之后，记下 所讨论的条目，并请参与讨论的用户评论并更正，因为只有提供需求的人才能确定是否真正获取需求。当最后拿到了一份详细准确的需求报告书的时候，会议就算成 功完成了。但是要清楚需求过程本身就是一个迭代的过程，在以后的过程活动中不可避免的将要修改和完善这份报告。

　　7、分析用户工作流程

　　分析用户工作流程观察用户执行业务任务的过程，通过分析使用实例得到系统的用例图。编制用例图文档将有助于明确系统的使用实例和功能需求，统一 建模语言的使用有助于与用户进一步交流。每个用例的描述应包括：编号，为每个用例分配一个唯一的编号，为需求的追溯提供了方便；参与者，与这个用例交互的 actor；前置条件，开始用例前所必须具备的系统状态；后置条件，用例完成后系统达到的状态；基本路径，用例完成的关键路径，也是用户期望的路径；扩展 点，基本路径的分枝，表示意外情况；字段说明，路径中名称的进一步分解说明，对以后类属性的定义和数据库字段设计起作用；设计约束，实现用例的非功能约 束。写基本路径时应该使用主动语句；句子以actor或者系统作为主语；一句表示一个actor动作，一句表示系统动作，交叉表现交互；不要涉及界面细 节，比如“用户在文本框输入名称，下拉框选择类型”。

　　8、确定质量属性

　　在功能需求之外再考虑一下非功能的质量特点，以及确定由于特殊的商业应用环境对系统提出的功能或性能上的约束，这会 使你的产品达到并超过客户的期望。对系统如何能很好地执行某些行为或让用户采取某一措施的陈述就是质量属性，这是一种非功能需求。听取那些描述合理特性的 意见：快捷、简易、直觉性、用户友好、健壮性、可靠性、安全性和高效性。你将要和用户一起商讨精确定义他们模糊的和主观言辞的真正含义，并且要将质量属性 分配到每个用例的设计约束中去。

　　9、检查问题报告

　　通过检查当前已经运行系统的问题报告来进一步完善需求客户的问题报告及补充需求为新系统或新版本提供了大量丰富的改进及增加特性的想法，负责提供用户支持及帮助的人能为收集需求过程提供极有价值的信息。

　　10、需求重用

　　如果客户要求的功能与已有的系统很相似，则可查看需求是否有足够的灵活性以允许重用一些已有的软件组件。业务建模和领域建模式需求重用的最好方法，像分析模式和设计模式一样，需求也有自己的模式。