每个开发组都应该形成并制定了一套工作习惯。下面将介绍一种我比较欣赏的工作方式一分工合作过程它是我最推崇的工作方式。AndyKraus当时在IBM工作非常清晰地描述了他的开发组与大量不同的用户组协同工作的经验。相信你能从这份报告中得到一些有用的启示。分工合作过程开发组与个人相比有两个优点:第一便于集中讨论;第二便于对研究的问题达成共识。然而分开工作却能编写更多文件。基于这个原因我比较喜欢的过程是:当需要集中研讨或对问题形成共识时让开发人员以整个组的方式工作其余时间则一个或两个人一起工作。下面是整个过程首先是大纲然后是详细说明。1.制定一份粗略系统功能图:对系统采用叙述达成共识(开发组);对应用领域达成共识并集中讨论系统主执行者和系统目标(开发组);编写系统描述(个人);收集各种系统描述(开发组)。2.制定详细的用例视图:集中研讨用例编写(开发组);对用例编写格式达成共识(开发组);编写用例(个人);审核用例(个人);审核用例(开发组)。第1阶段:制定粗略的系统功能图第1阶段分4个步骤完成。第1步 对系统采用的叙述达成共识(开发组)整个开发组聚在一起弄清楚系统应该描述什么及怎样对系统进行描述。首先每个人写一份系统叙述内容可能相同也可能不同。然后开发组阅读并讨论这些系统描述对应该描述什么、怎样描述及其长度以及哪些细节应包含、哪些细节不需要包括等达成一致。这可能需要花数小时。最后整个开发组对要构造的系统有一个清晰认识。第2步 对应用领域达成共识并集中讨论系统主执行者和系统目标(开发组)开发组应花费足够的时间找出系统总体目标、范围、主执行者。然后建立一个直观的描述一个输入输出列表一个设计范围图一个主执行者及项目相关人员列表以及一个最重要的初始用户目标集列表。这些条目都互相关联因此讨论某项时可能会牵扯到对其他各项的理解。采用这种方式可以在同一时间建立起所有条目。如果开发组认为他们已经弄清楚了所要建立的系统那么这可能会花几个小时到一天时间;如果他们还不知道则可能需要数天来完成这项工作。最后要对讨论域的范围、建立什么系统及关键执行者达成共识。第3步 编写系统描述(个人)开发组分散工作分别对系统所需求功能写出使用描述。开发人员单独编写系统描述然后和一个同伴进行交换或在一个几个人的小组内传阅最后把结果送到整个开发组。第4步 收集各种系统描述(开发组)开发组共同讨论描述的内容。回答“这是我们想要建立的系统吗?”这个问题可能会对系统描述进行多次讨论甚至重新编写系统描述直到开发组成员都认为系统叙述正好描述了他们想要的系统。到此为止第1阶段工作完成团队应向每个投资方发送一份系统叙述它显示新系统草图(低精度)应该包括如下各项:系统构想陈述列出哪些在领域中和哪些不在领域中(包括功能和设计范围)在执行环境中的系统草图关键的主执行者列表项目相关人员及其相关利益列表最重要用户目标列表系统描述集(至少半页)第2阶段:制定详细用例视图第2阶段分五个步骤完成。第1步 集中研讨用例编写(开发组)首先提出一份需要编写的用例详细列表。然后列出在系统生命周期中可能遇到的主执行者以及所有能够想到的针对主执行者的用户目标。由开发组采用适当技术对其审核、集中讨论。当然也可以分组进行这步工作。处理庞大的、不同种类开发组的一个有用技术是将它分成3到4人的工作小组。通常系统有几个领域或兴趣组每个组都需要用到相关知识因此工作小组应至少从每个领域组中抽取一人使得每个工作小组都包含讨论所需的各方面知识也便于小组成员相互了解。小组比大组行动迅速。同时这种分组方法使得工作小组的讨论能同时覆盖系统多个领域。如果要采用分组的方法构造所有主执行者和用户目标列表那么还需要把各小组组织起来同时把各组的结果也汇集起来作为整体重新对该列表是否能完成和是否能接受进行评审。最后开发组将得到一份临时的、所有需要编写的用户目标用例集。当然随着时间推移还会发现新的用户目标。开发组公布主执行者及用户目标列表。与此同时还可能对用例开发优先级、复杂度评估及开发时间等做一些附加讨论。第2步 对用例编写格式达成共识(开发组)这一步中整个开发组首先一起编写用例样本(或者每个人先编写然后把每个版本放在一起综合)。开发组讨论用例编写层次和风格、用例模板、项目相关人员及其的利益、最小保证等。到这步结束时应该形成一个初步的用例编写标准。第3步 编写用例(个人)在这个阶段整个开发组按专业重新分成小组每个小组由2到4人组成并为每个专业小组选择用例。花费几天或数周时间各小组独自或成对编写用例(我没有发现更大的分组有利于用例的编写工作)。然后在小组内传阅不断改进草稿直到编写正确。然后编写概要用例。在用例编写过程中小组成员肯定需要对某些用例分解创建子功能用例增加一些主执行者和新的目标等。在这步工作中对每个用例指定两个联系人甚至可以将其中一人指定为主要编写者这是非常有用的。在编写过程中会出现很多关于业务规则的问题这其实是系统真正需求与原来约定之间矛盾造成的。这种工作方式便于一个人回答相关人员对业务规则的询问同时另一位人员还能对即将开始的用户界面以及用户目标是否在正确的层次进行复检。第4步审核用例(个人)用例编写人员可以通过电子方式或直接通过纸面方式传阅用例草稿。有趣的是使用纸面方式有特别的好处。因为纸上保留了每个员工的评论编写者可能只需对用例做一遍编辑便可集众家之长。一个开发组说他们曾试图采用在线建议的方法但是由于用例要进行反复修改根据一个人的建议修改后还需要查看这些修改是否满足其他人的建议因此他们放弃了这种方式。但无论在任何情况下传阅用例草稿的双方都应该对用例编写层次和业务规则进行检查。编写者把用例发送给系统开发人员和系统应用专家进行审核。技术人员确定用例是否包含实现所需要的各种细节(数据描述和用户界面设计除外)应用专家应确定系统需求是否确实如此以及业务过程是否真正以这种方式工作。第5步 审核用例(开发组)最后对用例应该有一个开发组对用例进行审核软件设计人员、业务专家、应用专家、用户界面设计人员都参加审核。用例编写完成后开发组根据项目以及项目的审核政策和审核机制建立一个他们认为最好的用例草稿。编写者应确保每一步都是可理解的、正确的并且足够详细便于实现。所有这些工作可以通过正式审核、非正式审核、用户审核及开发人员审核来进行。一旦系统用例草稿通过了用户和技术专家详细检查用例就达到了第一个正式的基本要求然后开始系统设计。此后对用例的修改应只限于修复错误而不应该改变用例的表达形式。很快就会看到编写用例草稿和完成用例之间的差别在完成用例编写时编者应该:指定所有扩展条件仔细考虑业务策略与失败处理的联系验证对项目相关人员利益的保护验证用例是否仅描述了实际需要的所有需求确保每个用例对用户和应用专家是可读的以及开发人员清楚地知道所要实现的系统。