也许，请自己的妹妹做志愿者参加软件项目的用例(Use Case)分析是一件比较危险的事情，尤其是在软件项目来自于好朋友的初创公司的情况下。这太容易被误解了：你的妹妹会觉得她被利用了，而好朋友会质疑妹妹是在帮你收集信息。尽管有这样那样可能出现的问题，我还是请她做了志愿者。我的朋友需要收集一类潜在客户的信息，这类客户恰好比较符合我妹妹的背景。她是从事艺术工作的研究人员，有兴趣多了解一些软件开发的内幕。我想，通过这个过程可以让她稍微学习一下软件开发，也可以让朋友的公司对更专业的客户有所了解。我不确定我的这两个想法是否正确。

IEEE 《软件》(Software)杂志近期发表的一篇文章提到，用例分析“事实上已经成为软件项目中获取需求的最佳实践方法”。用例分析是一个相对简单的过程，与市场营销中的焦点小组分析过程类似，把最能代表潜在用户的一组人集中起来。在本案例中，软件公司希望的用户代表包括：一名年轻的工程师、一名只用邮件和文字处理软件的业务经理、一名带幼儿的母亲、一个用计算机搞创作的人、一个用多种计算机程序工作的人、一名教师和一个至少用一半时间照顾他人的女人（最后一个人就是我妹妹）。

用例小组的每个成员，通常被称为“角色(actor)”。开发人员向角色解释软件的基本目标。然后，开发人员就软件的操作征询每个角色的意见：软件需要做什么、不做什么；哪些操作有用，哪些没用；哪些任务是软件必须实现的，哪些是肯定不做的。与其他从潜在客户收集信息的方法相比，这个过程很直接，也更通用。在这个过程中采用一组概念和图表，比其他任何一种工具都简单得多，并使用一种规范的语言，称为“统一建模语言”。

虽然很简单，或许正是因为太简单，用例分析偶尔还会遭到软件工程社区部分人的批评。其中包括用例分析常常不一致，用例太详细了或是不够详细。可能最严重的指责是，用例分析将信息收集的过程和开发者对软件的推广工作混为一谈。工程师努力将软件要实现的功能教给用户，而不是听用户告诉他们软件应该具有的功能。当然，一些抱怨几乎对软件工程的任一方面都适用。软件工程比其他任何形式的工程都更加强调一个学习的过程，在软件开发过程的每一步，软件工程师都必须学习新东西。他们必须学习用户需求，以及开发环境如何支持软件开发。他们需要发现错误以及思想的局限性。在这种环境中，就不奇怪为什么最近大量的软件创新都强调软件开发团队应致力于学习或是自我教育的过程。

除了软件工程的一些论文，敏捷宣言，也许是除了软件工程文献外最尖锐的声音了，最终认识到了软件开发自我学习的本质。据其总结，“每隔一段时间”，开发团队“反思如何变得更有效，然后相应地调整其行为”。在现代软件开发中，这些“定期的时间间隔”是非常短的。随着每次新软件版本的发布，软件工程师们都会回顾这一阶段的经验教训，这种反思可能每年或是每6个月就会发生一次。在现代开发环境中，软件工程师们每周、甚至每天都会反省。很多时候，软件工程师们通过晨会开启一天的工作，每个参与者都会被问及四个问题：“哪些工作已经完成？”“今天的工作目标是什么？”“遇到了什么问题？”以及最后“有什么收获？”

软件工程师不仅需要学习系统需求，还需要学习使用的软件栈和算法，甚至是调试和测试程序的方法。软件工程是一个非常复杂的领域，在这个领域产生的问题，用传统的工程方法解决不了。由于我在软件行业从业多年，所以有很多机会思考软件工程师的决策问题。我对很多复杂的软件体系结构、晦涩难懂的数据格式、甚至是异常复杂的代码，感到十分困惑。我不止一次地得出结论，软件开发人员要把工作做好，仅仅学习技能是不够的。

一些现代作者，包括行业领袖如伊瓦尔·雅各布森(Ivar Jacobson)，都将编写软件视为工程和工艺的组合。在工程方面，从业人员注重构建知识和标准的实体；在工艺方面，匠人们注重掌握知识。雅各布森写到，编程“作为工艺学科，建立在软件‘大师’们的经验基础上”，“大师”即那些已经掌握如何编写程序并将经验传授给他人的人。一位更早期的作者，普林斯顿大学教授迈克·马奥尼(Mike Mahoney)，将软件工程与建筑设计师的工作相比较，建筑设计师花费大量的时间在类似用例分析的工作中。他们努力理解用户如何使用建筑，需要哪些功能、不需要什么功能。马奥尼写到，“建筑设计发展的历史与工程不同”，建筑设计的历史较少关注理论，而对人与建筑的关系更感兴趣。他还指出，“我们训练建筑设计师的方法与工程师不同”。

也许，请自己的妹妹做志愿者参加软件项目的用例(Use Case)分析是一件比较危险的事情，尤其是在软件项目来自于好朋友的初创公司的情况下。这太容易被误解了：你的妹妹会觉得她被利用了，而好朋友会质疑妹妹是在帮你收集信息。尽管有这样那样可能出现的问题，我还是请她做了志愿者。我的朋友需要收集一类潜在客户的信息，这类客户恰好比较符合我妹妹的背景。她是从事艺术工作的研究人员，有兴趣多了解一些软件开发的内幕。我想，通过这个过程可以让她稍微学习一下软件开发，也可以让朋友的公司对更专业的客户有所了解。我不确定我的这两个想法是否正确。

IEEE 《软件》(Software)杂志近期发表的一篇文章提到，用例分析“事实上已经成为软件项目中获取需求的最佳实践方法”。用例分析是一个相对简单的过程，与市场营销中的焦点小组分析过程类似，把最能代表潜在用户的一组人集中起来。在本案例中，软件公司希望的用户代表包括：一名年轻的工程师、一名只用邮件和文字处理软件的业务经理、一名带幼儿的母亲、一个用计算机搞创作的人、一个用多种计算机程序工作的人、一名教师和一个至少用一半时间照顾他人的女人（最后一个人就是我妹妹）。

用例小组的每个成员，通常被称为“角色(actor)”。开发人员向角色解释软件的基本目标。然后，开发人员就软件的操作征询每个角色的意见：软件需要做什么、不做什么；哪些操作有用，哪些没用；哪些任务是软件必须实现的，哪些是肯定不做的。与其他从潜在客户收集信息的方法相比，这个过程很直接，也更通用。在这个过程中采用一组概念和图表，比其他任何一种工具都简单得多，并使用一种规范的语言，称为“统一建模语言”。

虽然很简单，或许正是因为太简单，用例分析偶尔还会遭到软件工程社区部分人的批评。其中包括用例分析常常不一致，用例太详细了或是不够详细。可能最严重的指责是，用例分析将信息收集的过程和开发者对软件的推广工作混为一谈。工程师努力将软件要实现的功能教给用户，而不是听用户告诉他们软件应该具有的功能。当然，一些抱怨几乎对软件工程的任一方面都适用。软件工程比其他任何形式的工程都更加强调一个学习的过程，在软件开发过程的每一步，软件工程师都必须学习新东西。他们必须学习用户需求，以及开发环境如何支持软件开发。他们需要发现错误以及思想的局限性。在这种环境中，就不奇怪为什么最近大量的软件创新都强调软件开发团队应致力于学习或是自我教育的过程。

除了软件工程的一些论文，敏捷宣言，也许是除了软件工程文献外最尖锐的声音了，最终认识到了软件开发自我学习的本质。据其总结，“每隔一段时间”，开发团队“反思如何变得更有效，然后相应地调整其行为”。在现代软件开发中，这些“定期的时间间隔”是非常短的。随着每次新软件版本的发布，软件工程师们都会回顾这一阶段的经验教训，这种反思可能每年或是每6个月就会发生一次。在现代开发环境中，软件工程师们每周、甚至每天都会反省。很多时候，软件工程师们通过晨会开启一天的工作，每个参与者都会被问及四个问题：“哪些工作已经完成？”“今天的工作目标是什么？”“遇到了什么问题？”以及最后“有什么收获？”

软件工程师不仅需要学习系统需求，还需要学习使用的软件栈和算法，甚至是调试和测试程序的方法。软件工程是一个非常复杂的领域，在这个领域产生的问题，用传统的工程方法解决不了。由于我在软件行业从业多年，所以有很多机会思考软件工程师的决策问题。我对很多复杂的软件体系结构、晦涩难懂的数据格式、甚至是异常复杂的代码，感到十分困惑。我不止一次地得出结论，软件开发人员要把工作做好，仅仅学习技能是不够的。

一些现代作者，包括行业领袖如伊瓦尔·雅各布森(Ivar Jacobson)，都将编写软件视为工程和工艺的组合。在工程方面，从业人员注重构建知识和标准的实体；在工艺方面，匠人们注重掌握知识。雅各布森写到，编程“作为工艺学科，建立在软件‘大师’们的经验基础上”，“大师”即那些已经掌握如何编写程序并将经验传授给他人的人。一位更早期的作者，普林斯顿大学教授迈克·马奥尼(Mike Mahoney)，将软件工程与建筑设计师的工作相比较，建筑设计师花费大量的时间在类似用例分析的工作中。他们努力理解用户如何使用建筑，需要哪些功能、不需要什么功能。马奥尼写到，“建筑设计发展的历史与工程不同”，建筑设计的历史较少关注理论，而对人与建筑的关系更感兴趣。他还指出，“我们训练建筑设计师的方法与工程师不同”。

有一次我问朋友公司的工程师从我妹妹那里学到了什么，有一个人说：“她经验丰富，让我们很意外。她知道很多事情该如何做，但没有耐心了解做的步骤。”当我问到是否因为她的意见改变了软件的设计时，他们很得体地回答道：“最终决定系统需求的，是所有用例角色的意见，而不是某一个人。”

后来，我有机会问我妹妹对这次经历有什么想法。她耸了耸肩说：“他们似乎很了解我，但我还是说了一些让他们感到吃惊的事情。”

我问她：“你认为他们从你那里学到东西了吗？”

我妹妹停顿了一下说：“也许吧。但如果他们学到了什么，那就是他们意识到自己并不是无所不知。”                                                               ■