小软件项目开发的管理

小软件项目开发的管理

作者：不详

  一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的 经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。

一、小项目的特点

　大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点:
　1.项目功能相对较少
　2.开发人员较少
　3.开发周期较短
　　另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.

二、小项目开发中常犯的错误 　　

　　小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:
　　1、开发之前没有认真地进行项目可行性和工作量的估计。　　往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。
　　2、没有真正的设计过程
　　开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。

　　这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。 　　另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。
　　第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解 以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。
　　3.不经过单元测试而直接进入系统测试
　　造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。
　　殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当 调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测 试，就会很容易消除一些隐患。真可谓欲速则不达也。

三.合理的开发流程

　　合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开 发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。
　　以下我从几个方面描述一下我认为比较合理的模式.

1.需求获取

　　在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。
　　软件项目可以大致分为专用软件和通用软件两大类。
　　对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。
　　但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。
　　对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用 什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。
　　为了比较好地与用户进行交流，使用一些工具是很有好处的。 　　为了讨论用户界面，可以用VB, delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)
　　为了讨论软件运行的流程，可以采用UML的Use Case图。

2.需求分析

　　在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的 分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。
　　这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。
　　我想强调几个问题。
　　一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。 　　二是需求获取与需求分析的关系。
　　用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。
　　例如当初采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。

　　三是分析与设计过程的衔接。
　　分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程 语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设 计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。
　　对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采 用其他的平台时，便可以以这份分析文档作为开发的基础。
　　对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。
　　现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。

3.设计过程

　　设计阶段的工作包括:
　　对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。
　　定义界面部分、数据访问(数据库)部分。
　　由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。

4.编码

　　进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。

5.测试

　　如前所述，即使是小项目，也应该严格地进行测试。

四、人员的安排

　　比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用，

　　经验告诉我几条原则:
　　1.协调几个人的工作比自己完成一段编码更重要.
　　由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。
　　只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。 　　2.给每个开发人员明确的任务书.
　　不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系 统。但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。
　　3.让大家都大致熟悉设计模型.
　　让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。

主页   论坛   留言   打印   联系  

创建成功的工程 

作者：Bruce Eckel，翻译：UMLChina.Hairui 

Bruce Eckel，著名的计算机语言和工程专家，著有《C++编程思想》（Thinking in C++）、《Java 编程思想》（Thinking in Java）等书籍 相关网站：http://www.bruceeckel.com –译者注 

以下工程开发指导是我对决定一项使用任何语言的软件工程成功与否的决定因素的一些认识。 

1．记住往往事与愿违 

纯粹的“轶事工程”（原文为：anecdotal project，其含义不好理解，暂译为”轶事工程”，盼指正–译者）的失败几率总是存在，一些低至百分之五十而另一些高达百分之八十，但是所有的这些都表明：你失败的机会大于你成功的机会。为什么我要从这个令人丧气的预测开始我的话题呢为每一天开始时，我都想“今天将会不同，我今天能够完成四倍数量的事情”，尽管（在此之前）有过一系列不间断的例外。对于软件工程来说，过度的狂热往往被那些（只）关心结果人所夸大——“这一次，我们将解决以前从来没有人解决过的问题，只需付出更少的时间和更小的代价”，尽管他们知道，真正的规则是：“你只能从此三者中选择一个”。 

记住你身后高高堆积的纸牌[i]非常重要。你手中有一根包含时代力量的魔术手杖或者是挂在悬崖上，会让你做出完全不同的两个决定。如果你懂得你的处境属于后者，你将会说：“是的，这很好。但首先让我们看看我们是否能够在现有的进度和预算情况下完成这一切。” 

一个将不稳定形势和对失败的认识放到显著位置的方法是研究过去的失败。一份很好的资料是Roberts Glass（一位爱好研究崩溃的专家）的著作：《软件失控》(Software Runaways,出版信息：Prentice Hall 1998)，以及他其它的著作。此外可以阅读Tom Demarco和Tim Lister的经典之作《人件——生产性工程和团队》 (Peopleware: Productive Projects and Team,出版信息：第二版，Dorset House,1999)。 

2．切合实际地安排时间 

时间安排的“魔法”经常受到非开发人员为满足软件开发实践之外的愿望和期待而产生的想法所驱使。最近我校正了自己的时间安排策略。我先将整个工程显示脑海中，然后闭上眼睛，清理自己的大脑并让它判断这个工程大概需要多少时间。如果不考虑奇怪的技术问题、各种会议和其他分心的事物的影响，得出的这个时间居然非常合理。但我建议将这个合理的时间乘以3，或许可能是4，并且加上百分之十。如果这个估计出来的时间将让你失去市场机遇，那么考虑不要进行这个工程。如果你认为像这样计划时间不合理，那么首先请注意，大多数工程将遵循这个规律。其次，试想一下，如果你所在公司的所有工程都很成功进行会带来局面：你将拥有更多的收入；更少的程序员会因为愚昧的工程时间安排筋疲力尽而退出。 

你也许还会争论说这个时间评估技术非常没有科学性，这一点我同意。然而，所有的软件评估技术都含有臆测和直觉的成分在内，甚至连功能点（原文为：function point，若有其他正规译法，请指正）分析都需要对功能点进行猜测。我的“信封背面”技术将所有臆测结合到了一起，而不试图假装没有猜测。用更少的时间，也许产生更好的结果。但是，我的猜测是建立在我自己的经验之上的。 

3．首先让它运作起来 

当我试图进行一些无意义的事情时，我最大的创造性成功来临了。铭记最重要技巧——当你开始一个工程时，你好比已经用手指将自己挂在一个悬崖之上；然后你考虑一下能够做什么疯狂的事情简单地让你的工程运作起来。这并不意味着你需要马上投入进去并用通常的方式开始撰写代码，你只需要尽早尽快找到一个转换周期非常短的工具，用来判断你是否可以做该项工作以及你的工程可行性如何。我在后面将要提到的Python语言就是这样一种工具。 

将你的计划运作起来有很多好处。凭你的经验，你应该知道，用户只有能够开始使用你开发的东西的时候才能理解你开发的是什么，然后他们会突然产生各种念头并对该软件应该做些什么真正提出要求。一份系统说明书往往只是一份文档，人们往往不会认真地阅读，但是如果你让他们体验一个可运行的程序之后，他们就会确切地明白你的意思。更早地了解用户们真正想要什么岂不是更好nbsp;

事情往往会比你想象出来的要复杂四倍以上，所以对你能够完成的东西要尽可能地保守一些。无论何时，一些不可知的因素都在伴随着你的工作（这一点你可以从产品描述中一些“最”中察觉到：“最快”、“最大”、“最新”），原型的价值不能进行夸大。如果在此之前你没有做过类似的工程，那么最重要的事情是尽快地判明该工程是否可以实现，开发一个根本不能发挥作用的程序将会以浪费你的大量金钱而收场。 

最后一点，优化。要能够在这个阶段抵抗得了诱惑。牢记Donald Knuth说过的话（其中略有一点开玩笑的意思）：“不成熟的优化是所有麻烦的根源”。虽然优化是一些工程的关键因素，但是在确认程序切实可行之前一切优化都是盲目的。在最后建造系统之前浏览一遍所有的问题。每个工程都有一些你没有接触过的东西，你应该首先将注意力放到这个领域，创建一个测试程序或者原型来寻找解决问题的方法。在你知道你是否可以做到并且知道做到的难度有多大之前，你没有其他办法能够得知工程是否能够成功、如何为它安排时间以及它需要多少付出等等。 

4．使用恰当的工具 

一个工程的早期部分应该是高度探索性和实验性的，因为那个阶段是发现自己不会做什么以及如何去建造程序的阶段。寻找最适合工具的最好方法是去体验一下他们，然后摈弃其中工作效率低下的那些。例如，你可能开始的时候用的是Rational Rose，后来决定使用Visio Professional来创建视图，因为你需要Visio（或者通过Versa）提供的一些特性。 

用来做工程的恰当工具并不一定就必须是你已经了解的编程语言。当使用一种语言时，你就被局限在该语言所能表示的范围之中了。如果你是一个C++程序员，你很自然可能想用C++创建所有的工程管理和工具。但当你需要更加灵活的工具时，Perl是一种更快速的选择（甚至将考虑学习需要的时间在内）。在你的实际工程开发中，使用Python来快速造型或者甚至交付一个内嵌Python语言的应用程序将给你带来更好的局面。首先，它是免费的，所以不需要支付任何许可授权费用；同时它对C 和Java有完全兼容的接口，你可以使用Python解决所有Perl能够解决的问题，所以它是C++和Java的一种完美的辅助语言。 

5．接口的设计 

在C++中，接口是一个包含所有虚函数的类；而在Java中接口技术被直接支持；在COM和COBRA中，你没有其他选择，你和所有的抽象打交道——所有的都是接口，没有实现。接口提供了一个更加整洁的设计方式。要想让程序员们确信这一点有些困难，但是它对将COM或者COBRA指定为构件模型非常有帮助的（COBRA技术也是与操作系统无关的技术）。它不仅仅提供了工程实现语言的灵活性，并让你能够完全地将工程切割开来。如果你打算在你的开发组或者公司之外实现你的工程的一部分，整洁的接口可以阻止任何与工程其它部分不适当的连接，同时你可以用任何语言来进行开发。你可以采取快速造型来实现所有的接口，稍后才对其中比较特别的部分进行优化。 

6．设计时充分考虑异常情况 

在C++中，异常控制并不像在Java中那样得到有力支持——这是Java在工程管理方面成功之处。在设计、代码编写和模块使用的时候往往会有一些错误，除非软件自身能够通过抛出一个异常来声明这些错误，否则你将会花费许多小时或月的时间来捕获这些问题。只有通过严谨的异常使用，你才能保证这些问题不会出其不意地让你的工程陷入困境。 

7．简洁往往付出代价 

虽然很难说服管理部门，但是“简洁”这个词是可维护性和复用性的同义词。不仅如此，一个简洁的程序让人感觉很好。但是因为我们确信软件工程是一种商业行为，目的是为了赚钱，而不是为了感觉，因此很难说简洁的程序比其他非简洁的程序更加有灵气地结合在一起。但是由于软件是一种能够赚钱的艺术实体，在美学和实用性之间必然会一场争论。 

8．人与人之间的交流是一个瓶颈 

这就是为什么小型的组队往往更加有生产力的原因。当一个工程像火焰一样失去控制的时候，将更多的程序员扔进火焰将使情况变得更糟。这也是为什么简短的小会议往往可以发挥作用而冗长的大型会议却做不到，还有为什么太深的管理机制会导致生疏的原因。参阅《人件》（早些时候提及过）一书了解更多的细节。 

解决交流问题的最好办法是免费的：在一台废弃的计算机上安装一个Linux服务器，你可以在几分钟内完成这项工作，自动安装将包括一个Apache网页服务器。然后将你们所有的文档，从测试分析到用户文档，拷贝到服务器上，以便每个人都能够访问到最新的信息。你可以轻松地加入Java Servlets或者Perl脚本（http://www.perl.com/）或者Python(http://www.python.org/)来收集每一页的内容，然后用一个List服务器来向所有的成员发送公告。如果你想用camera-ready格式来提供文档，你可以用Adobe Acrobat格式来代替HTML格式。如果你的工程足够大的话，指定一名成员专门负责维护服务器是值得的。 

9．制定一份计划（可以是任何类型的） 

我曾经见过许多工程在没有签订任何合同（更别说一份计划）时已经有大量资金流动。哪怕是对于一个很小的工程，你也需要某种计划，甚至它可能只是被写在一个信封的背面或者只存在于主程序员的脑海中。当工程逐渐变大，你需要一个回顾的过程。一个典型的计划包括：分析阶段（包括你打算用程序解决什么问题以及程序将完成什么）、设计阶段（程序如何完成它的任务、程序实现的组成、分析阶段预定目标是否达到的测试使用信息以及发布、安装和培训等事项）。当新的信息被收集时，这些阶段将被重复。根据工程的大小，这些步骤将被缩小或者放大，但你必须像熟悉你的编程语言一样熟悉它们。 

10．考虑外部帮助 

一种放弃：我的公司提供培训和咨询服务，因此当然我感觉这是一个好主意。然而，如果你的公司内部有经验丰富的人可以担任你的工程的顾问，你可以不必向公司之外寻求帮助。这是一种以知识为基础的商业行为，生产力最低和最高的软件工人之间的生产力差别是很大的。如果你无法雇用那些最有生产力的工人，你可以通过培训提高他们的生产力，通过咨询和代码预排来改进你的工程的分析、设计和实现。对于顾问和客户来说，有一本优秀的书籍是Weinberg的《咨询的秘密》（出版信息：Dorset House,1986） 

另一方面，我曾经见过一些工程中，使用外部的开发组队剥夺了内部的队伍的权利，该项目最后以花费更多的时间和资金收场。这将我们带到我的最后一个提示: 

11.了解永远没有银弹（原文为：silver bullets,此处直译为银弹，估计引申含义和free lunch接近）的道理 

这句谚语是由Fred Brooks发明的，对于今天仍然适用——尽管有许多“银弹”已经被发明出来了。统一建模语言（UML）就是这样一个例子：它当然是一个很好的通用词汇表和设计符号集，但是UML仅仅轻微地减少了方法学家之间的争论而已。永远不会有不劳而获的事情。你必须艰辛地计划你的对象、它们的接口和结构，然后跨越一道道障碍将工程变成成果。你必须清楚没有任何可以保证成功的方案可以依赖，同时牢记工程的失败的几率让自己更好的瞄准成功。

主页   论坛   留言   打印   联系  

成功项目管理的秘密 

摘自SDMagazine，Karl Wiegers著，UMLChina.Shids译 

在最好的情况下，管理软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。 

1. 定义项目成功的标准 

在项目的开始，要保证风险承担者对于他们如何判断项目是否成功有统一的认识。经常，满足一个预定义的进度安排是唯一明显的成功因素，但是肯定还有其他的因素存在，比如：增加市场占有率，获得指定的销售量或销售额，取得特定用户满意程度，淘汰一个高维护需求的遗留系统，取得一个特定的事务处理量并保证正确性。

2. 识别项目的驱动、约束和自由程度 

每个项目都需要平衡它的功能性，人员，预算，进度和质量目标。我们把以上五个项目方面中的每一个方面，要么定义成一个约束，你必须在这个约束中进行操作，要么定义成与项目成功对应的驱动，或者定义成通向成功的自由程度，你可以在一个规定的范围内调整。相关的详细信息，请参照我的《创建一种软件工程文化》（Creating a Software Engineering Culture）（Dorset House, 1996）中的第二章。 

3. 定义产品发布标准 

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以把发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与你的客户指的“质量”一致。 

4. 沟通承诺 

尽管有承诺不可能事件的压力，从不作一个你知道你不能保证的承诺。和客户和管理人员沟通哪些可以实际取得时，要有好的信誉。你的任何以前项目的数据会帮助你作说服的论据，虽然这对于不讲道理的人来说没有任何真正的防御作用。 

5. 写一个计划 

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划。困难的部分是作这个计划–思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。 

6. 把任务分解成英寸大小的小圆石 

英寸大小的小圆石是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确的估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。 

7. 为通用的大任务开发计划工作表 

如果你的组经常承担某种特定的通用任务，如实现一个新的对象类，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他/她必须处理的大任务的每个实例相关的工作量。 

8. 计划中，在质量控制活动后应该有修改工作 

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用作任何的修改，很好，你已经走在了本任务的计划前面。但是不要去指望它。 

9. 为过程改进安排时间 

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投资一些时间在过程改进上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100％的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。 

10. 管理项目的风险 

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。要一个软件风险管理的简要的指南，参见我的文章“Know Your Enemy: Software Risk Management”（Oct. 1998）。 

11. 根据工作计划而不是日历来作估计 

人们通常以日历时间作估计，但是我倾向于估计与任务相关联的工作计划（以人时为单位）的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求，会议，和所有其他会让时间消失的地方。 

12. 不要为人员安排超过他们80％的时间 

跟踪你的组员每周实际花费在项目指定工作的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。 

13. 将培训时间放到计划中 

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。 

14. 记录你的估算和你是如何达到估算的 

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。 

15. 记录估算并且使用估算工具 

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即产品大小，小组大小和进度安排组合起来没有已知项目成功的情况。Software Productivity Centre(www.spc.ca)公司的Estimate Pro是可以一试的好工具。 

16. 遵守学习曲线 

如果你在项目中第一次尝试新的过程，工具或技术，你必须认可付出短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。 

17. 考虑意外缓冲 

事情不会象你项目计划的一样准确的进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为填料，而不是明智的承认事实确实如此。指明一些以前项目不愉快的意外，来说明你的深谋远虑。 

18. 记录实际情况与估算情况 

如果你不记录花费在每项任务上的实际工作时间，并和你的估算作比较，你将永远不能提高你的估算能力。你的估算将永远是猜测。 

19. 只有当任务100%完成时，才认为该任务完成 

使用英寸大小的小圆石的一个好处是，你可以区分每个小任务要么完成了，要么没有完成，这比估计一个大任务在某个时候完成了多少百分比要实在的多。不要让人们只入不舍他们任务的完成状态；使用明确的标准来判断一个步骤是否真正的完成了。 

20. 公开、公正地跟踪项目状态 

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正操作，并且在条件允许时进行表扬。 

这些提示不能保证你的成功，但是它们将帮助你在你的项目上获得一个坚实的把手，并且保证你做了所有你可以做的事来让项目在这个疯狂的世界上成功。 

原文链接：http://www.processimpact.com/articles/proj_mgmt_tips.html

主页   论坛   留言   打印   联系  

更好地领导一个项目的诀窍

—-Warren Keuffel

自：SD Magazine，Sep,1999. UMLChina.Think译

—————————————————————————-

　技术管理就像开车。当你做得正确时，没有人注意，一旦某个环节出错，问题会接踵而来。以下是我11年来作为Interviewing Manager的Team管理体会，排名不分先后，你必须注意每一点。

1. 不要重复过去二三十年来别人犯过的错误

　这句话来自Steve Mcconnell，IEEE软件编辑和软件开发畅销书作家。Mcconnell的作品包括经典著作“Code Complete”。Mcconnell认为，“大量阅读”是避免凡重复错误的最好方法。

2. 80%的管理就是选择正确的人选

　Scott Adams, Dilbert漫画的作者认为一个好的项目经理必须创造一个人尽其用的环境。所有的项目经理都应该读一读Tom Demarco和Tim Lister的新书“Peopleware：Productive Projects and Teams”（2nd Edition, Dorset House, 1999）。

3. 总是试图雇用比你强的人

　不要让你的自负成为项目的瓶颈。组织一支聪明的队伍，给他们足够的资源和解决问题的规则，让员工自己解决问题。

4. 不要浪费时间

　Tom Bragg，Intellisys Technology Corp.的首席技术官员，认为太多的项目由于不能如期开始最后陷入麻烦。通常导致延迟的原因包括其它任务的干扰，人事变动，不准时的经理等等。

5. 最优的未必是最大的

　Tom Bragg的另一个建议是：密切注意项目开始后发生的事情。Bragg说：“计划好你的工作然后如期进行，过分紧张的工作强度反而往往导致生产率的降低，可能保持每周50小时以内的工作强度是最佳的。

6. 真实的，公正的估计

　项目经理应该避免“依照管理者的欲望修改计划”的陷阱。“一个有效的估计的特征是所估计的时间与金钱比实际情况低和高的概率相等”，Bragg说。

7. 使你的组织结构更有效率

　很多情况下，你可以采用另外一种与现在不同的组织结构。看一看Apache Web server的开发小组，他们的层次组织并不分明，却开发出了成功的产品。

8. 使用WWW上的免费工具

　从http://sunnet.usc.edu/winwin/winwin.html，你可以下载由Barry Boehm的学生开发的，能够把W理论（WinWin模型）和螺旋形模型结合起来的工具。在项目管理研究所的网址www.pmi.org，你可以下载它的联机手册。从www.spmn.com你可以看到从CMM模型出发的一些建议以及两套工具：Control Panel和Risk Radar。Control Panel是Excel表格形式，由于监测生产率和质量；Risk Radar是一个Access数据库，对项目的风险进行量化管理。

9. 不要小看老程序员

　重新训练现有的程序员比雇用新毕业的大学生要有价值。老的程序员在以往的多个项目上有丰富的经验，通过新技能的训练后，他们的经验和知识会帮助年轻的程序员（包括项目经理）节约时间和金钱。

10. 为你的项目选择定正确的工作流程

　并不是所有的项目都适用一种开发流程。Intel公司有规律地检查每个开发小组的工作质量，如果出现了延迟交付或质量问题，Intel鼓励该小组改进他们的工作流程。

11. 做好你的生存计划

….

主页   论坛   留言   打印   联系  

参与变革

 
———发现更多可重用的过程与简单的版本控制相比，更易走向成功 

Lisa J. Roberts，译：umlchina.mirnshi(mirnshi@263.net) 

译者序：本文刊登于SDMagazine，2000年11月。论述了为什么要建立可重用过程以及从中得到的好处。译文中部分语句采用了意译，不妥之处和曲意之处请参见原文。 

对开发过程共享实施猛烈的变革和改变是个什么样子了可能的时间大量损失（好，其实这是很小的

可能，除了正在改变开发过程时），当它们获得了人们支持时就都会成功。 

在历史上，人民，社会的劳动者，通过联合推动了社会变革。这就是我们所满意的应用程序，MeshTV，用二维和三维的有限元网格以图形的方式可视化和分析数据。它也能处理多种不同的网格类型，提供各种方式查看数据并去除了大多数的硬件和厂商的依赖，同时以自身图形硬件的速度显示图形。MeshTV也可以并行工作，你可以想象得到这需要一些组织级别满足程序的复杂性，保持有序。最后说一点，MeshTV大约有450,000行源代码。 

这是我所作的全部描述。如果你想了解得更多，查看www.llnl.gov/bdiv/meshtv，你可以下载可执行程序、源代码和手册。 

受约束的混乱 

象许多为内部使用而开发的程序一样，在加利福尼亚Livemore的劳伦斯Livemore国家实验室，对程序必需的修改和增加超出了可用的资源。在MeshTV项目中，这导致了混乱，（on the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（译者注：这句话不好译）没有人有时间坐下来画出应用流程。我们都在实验室的里里外外，忙于我们客户的贪婪的需求。（有约150个文档用户-可能更多，实际上要靠5个兼职的开发人员支持）在我们这种状况下，这种过程导致了我们用户更多的抱怨和可靠性匮乏的程序。 

三年前，我们的职责很小（几个用户，几个开发人员，很少有广泛的应用功能）允许我们在CVS上用非常不正规的过程管理源代码。当用户数和他们需求差异增多时，相应的代码管理的复杂性也增加了。处理我们增长的工作量也变得更加困难，我们知道有些事情必须要改变了。我们决定加入到我们部门的其他开发小组中去，并使用Rational软件公司的版本控制系统—ClearCase。从此，我们过程的改进氛围（our process improvement culture）开始改变，变革的种子已经播下了 

在我们转向ClearCase前，我们小组的一位经理曾经诱导我们更多的集中在过程上，她徒劳了。她看到了增长的压力和用户的不满，她想我们应该尝试用不同的方法提高我们程序的可靠性和在用户那里的名声。不幸的是，她的话从来没有引起重视，同样我们也认识到了这点，但我们不得不忙于作完我们的工作。开发人员认为最好的情况是软件工程学所论述的那样，而在最糟和最可能的情况下，会占用大量的时间，提供众多的文档，用处不是很大。我们的一些老开发人员认为改进我们的过程没有用并且……（Some of our veteran developers saw no use for “improving our process” and would have sooner appeared in public in a tutu rather than utter such a sissy phrase.）（译者注：这句话太难译了，单词也不认识）而且俱乐部所有人，包括我也怀疑我们要收获的巨大好处。我认为CVS工作得很好，我们真的不需要更多先进的东西。 

在CVS工作的同时，ClearCase工作得更好。我认为在每个软件工程生产力上没有真正的提高，但是可以用我以前不能采用的工作方式工作。这些新的工作方法可以使管理源代码变得更容易，同时也减少了我曾经在CVS中遇到的问题。例如，我现在可以轻松的多并发地开发，我可以在我完成后可靠的归并我所作的。新特性弥补了我花在开发和学习新过程上的时间。 

真正的产出 

过渡不久，一位同事和我与一位来自苹果计算机公司的开发同行进行了一次有趣的讨论。他的工作需要产品开发过程的急迫应用，包括构建方法学和发行版本管理过程。当我们叙述我们通常随意无计划的方式时，他几乎震惊晕倒。后来的讨论，使我们惊奇的了解到了通过改进我们的过程所获得的好处。有一位经理鼓励我们是一方面，但是非同寻常的另一面是听到一位开发同行称赞他发现的好处。这是真正的产出，计算机科学风格的。 

我们对其思考的越多，我们越认识到我们需要行动。将新特性和缺少固定发行日期联系起来的狂热，导致了在发行新版本和功能性的匮乏测试间长久的延期。我们的意图是好的，我们想让我们的客户满意。然而，不知何故，我们的期望事实上很糟糕，似乎看起来我们工作得很辛苦，但是，我们听到了更多的抱怨。我们需要改变现状。 

首先，我们转换到有目的的发行版本日期，使其包含明确的更改和新的功能。像许多的内部产品，MeshTV有着明显的直接的用户（MeshTV had users who lived “right down the street.”）。新特性的不同的声音淹没在所有的目标回应中，我们尝试经常性的从那些所有从会议厅走下来，停下来聊会儿天的用户那里获取要求。（这些打断也可以避免我们持续工作）荒谬的是在试图获取所有要求中，我们不能满足他们中的大多数，我们失望了。所以我们从这种方法上退回来。或者试图将所有要求放进去（可能匆忙地完成，没有更多明显的bugs）,或者针对最后的抱怨作一个改正（从而没有旧的要求）。我们需要一个载明新发行版本应体现哪些要求的计划。 

这表明另一个过程需要改进。在决定之前，我们通过将bugs报告和要改变的要求写到纸上，保证可追踪。这片纸经常“走向了所有事物的归途”，或者偶然的扔进了废纸篓，或者压在了其他所有的纸张下面。（这点上我坚信我已危险地靠近制造我自己桌面中子星）（译者注：黑洞乎）那些纸随着时间的流逝而不能理解，无心的造成了客户输入损失的结果。 

我们需要很好的保持我们改变要求的追踪，这样我们就可以为下一个发行版本选择明确的要求。在对几个产品调研后，我们购买了Pure Atria的ClearDDTS，帮助我们管理我们的改变要求，我们试图一年四次发布新版本应用程序，这作为一策略被我们采纳，这样我们就可以很快的清晰地增加新功能，不用更新得过于频繁导致没有时间测试我们的修改。为了达到结束点，我们努力选择一定量的能够在三个月内完成的工作。第一次时，因为我们没有人知道如何预测一个详细的修改需要多长时间，我们彻底失败了。幸运的是，我们可以通过ClearDDTS跟踪我们曾经预测的时间和工作中实际花费的时间，并且个别开发人员利用这些数据预测将来。在为其他版本的选择工作中，这获得了重大的成功。变革明显的站住了脚。 

我们也决定与目标发行版本并进，着手提高质量的工作。为了完成这点，我们要求所有决意要改变的要求要被不具有开发责任的其他人所验证。当我们知道其他人会检查工作时，我们就都会非常仔细，这多么惊奇。我们也开始采用Mercury Interactive’s Xrunner和内部使用的脚本开发了一个自动测试系统。将来，在我们发布一个新版本应用程序前，这些测试必须成功的测试过。 

持续的改进 

所有这些工作都以我们不能想象的方式的到回报了。我们更好地跟踪我们的改变要求，也就是我们没有丢掉它们，我们确实能跟得上用户的更新状态了。用户喜欢这点，我们也不再面对来自客户的挫折。他们也喜欢我们更频繁的更新和更加健壮的程序。 

我们正在寻找另外的方式，我们可以从改变我们过程中获得好处的方式。现在，我们正在研究软件开发成熟度模型（CMM）,看是否能通过遵从2级帮助我们提供更好的应用软件（请到http://www.sei.cmu.edu/查看更多的CMM信息）。我们可以从这种方式中获得好处，但是我们想确认通过2级认证能够编写更好的代码，不只是更多的文书工作的要求。我们的兴趣在于进步，不在于核对boxes。 

我们正在进行的另一个改变是，我们能够更容易地在我们每年四个主版本之间发布修订bugs的版本。这点可以是我们更快的转向用户的要求，平息用户的愤怒。（我们基于用户认识到的严重性和我们察觉的严重性的比较，选择哪些bugs被改正，还包括工作区存在的风格。我们在整体上也为客户整合了全部优先级的感觉） 

我们过程改革的更多惊人结果之一是不只影响了程序，更多地影响了程序开发人员。他们停止了改善用户的态度，转向提高应用程序。程序变得更可靠，发行版本变得更可预测的同时，用户对应用软件整体上也更加满意。 

但是我们不仅只关心我们的过程的改革。MeshTV的开发人员同其他的开发小组并同工作着，我们试着同其他的小组分享我们的经验，学习我们的胜利和错误。围绕我们新的过程，我们提供了四个展示，至少有一个小组已经决定采用我们的一些经验。变革在成长。 

成功孕育成功 

当管理层尝试推动改变过程时，从最初的怀疑和愤怒，我们在这个过程中经历了巨大的变革。这些曾经著名的过程都是那些所有刊物都讨论过，当作福音传授给我们的同事。当我回头看看我们的小组，我惊奇于我们从使用一个版本控制系统改变到几个可重用性、文档化过程，甚至将那些经验出售给别人。什么能够允许我们背离我们正规的商业方式 

对于我们来说，在开展新的过程中最重要的因素是一个成功的战士，他酝酿了过程改革中的兴趣。这个战士应该是一个受到尊敬的开发人员，在小组里的，因持续工作而闻名，因渴望经验的增长而受人尊重。在我们的事中，我们有二位战士，我的同事Sean Ahern和我自己。在我们兴奋于可能的好处并开始着手于一些改革后，小组的其他人信服了并跟随我们。当管理层决定了过程必须跟随时，来自小组外的压力出现了。对于外来的，组员将可能排斥它，对此我不能强调得足够多。然而，来自里受人尊敬的组成员的狂热，开发人员感到是必须听从。毕竟，这些人们事实上知道到底它象个什么样子。一旦其他团队里的人看到了真正的好处，他们就会跳进这个潮流中，变革也就会良好的进行下去。当开发人员开始思考改进过程的方式，获取真正的好处时，好戏就开始了 

你如何开始你的变革次一个改变。一旦明显有好处，你的同事就会加入到你的行列中，同你一起征服编程世界。

主页   论坛   留言   打印   联系  

CMM、TSP、PSP讲义稿

Blueski 

　　CMM/TSP/PSP应该是目前世界上公认的最好的软件管理模式。

    CMM提供了框架和目标，PSP针对个人进行优化，TSP针对团队进行优化。

    以下提供的是一些CMM/TSP/PSP 介绍的幻灯片。压缩为cmmtsppsp.zip，打开后共有4个文件，其中cmmtsppss.ppt是主文件，带有对其它文件的连接。

    点击下载：

    下载–>> CMM、TSP、PSP讲义稿

此致

2001-8-30制作

主页   论坛   留言   打印   联系  

开发流程中的可用性

来源：

http://www.microsoft.com/China/msdn/msdnonline/features/articles/uicycle.ASP

Microsoft Corporation
2000年10月

摘要：本文讨论反复、周期性的设计过程，包括以用户为中心进行设计的四个原则、两种类型的产品设计过程，以及可用性活动如何渗透产品开发的各个阶段并为其带来益处。

目录

·         简介

·         使用反复、周期性的设计过程

·         构思阶段

·         规划阶段

·         开发阶段

·         稳定化阶段

·         为下一版本做准备

简介

可用性测试为您带来的好处

简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您在最后的处理过程中省去重新开发这一环节。

本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、开发、稳定化以及为下一版本做准备。

在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用、易于学习，并会长期使用。

使用反复、周期性的设计过程

反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：

·         及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。

·         综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。

·         及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。

·         反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。

多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越难。

相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。

螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。

构思阶段

产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、风险评估以及项目构架。

在构思阶段，通常进行下列可用性活动：

环境研究

基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一书中所述的方法，此类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。

环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并不是不可或缺的。

环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。

竞争性测试

通过竞争性可用性测试，您可以为产品设置量化的可用性目标 — 任务完成的速度、每项任务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成任务时的性能。

竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争 — 产品必须比现有的进程更有效、更好。

进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、最重要的功能。

用户/受众分析

了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关的，例如：

·         计算机使用经验

·         年龄

·         接受培训的程度

·         用户群之间的社会关系

·         特殊要求（可访问性）

您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具体的群体而不是普通大众。

规划阶段

规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft Visual Basic创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着手测试是非常值得采取的做法。

根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。

用户情况

创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。

任务分析

任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务的逼真度进行分析。就产品的特性而言，任务的完整性如何析逼真度意味着观察用户完成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。

一些要考虑的问题和活动：

·   &

来源：超越自己