现代软件工程讲义设计阶段 典型用户.docx
《现代软件工程讲义设计阶段 典型用户.docx》由会员分享，可在线阅读，更多相关《现代软件工程讲义设计阶段 典型用户.docx（24页珍藏版）》请在冰点文库上搜索。
现代软件工程讲义设计阶段典型用户
当我们写一个软件的时候,都知道要为用户考虑,但是用户在哪里?
有同学写“图书馆管理系统”-说来图书馆的同学都是我的用户,但是他们有没有区别呢?
有同学写“自动柜员机系统”,那到底有多少类型的用户来到柜员机前呢?
这些都是团队成员在需求分析和设计阶段要反复琢磨的问题。
有同学说,我把用户的愿望百分之百地实现了,这不就行了么?
不要搞那么多分析啊,故事啊,心理啊,讨论啊,文档啊… 请看这个笑话:
在长时间一丝不苟的实现之后…
得到了和用户要求一模一样的产品!
但是用户满意吗?
光看用户的表面语言或行动还是不够的。
我们还要找到用户语言行动背后的动机!
（图像来源:
有同学会说,我只要把产品做得可扩展性特别好,一般用户到超级用户都能搞定就行了!
且不论这是否能覆盖所有用户,一味追求“最大的扩展性”也有很多副作用。
几年前有一款www浏览器有不少安全性的问题, 安全专家在忙于补救各种安全漏洞之时,发现它的“网站地址栏”允许的最长输入是4兆个字符!
4百万个字符啊,多适合做缓冲区溢出的攻击啊!
但是有哪个正常的网站或用户要输入这么长的网址呢?
[讨论]
VisualStudio是一个非常成功的软件开发集成环境（IDE）,它支持VB/C/C++/C#/ASP.net/WPF/…等等不同的开发语言和套件,用户可以写几行的helloworld程序,也可以写几万行的多线程软件, 它还支持项目管理,测试工具,以及第三方的插件…它的众多用户分布在全世界大大小小的国家, 各行各业的公司,大大小小的团队, 有些是业余爱好编程,有些是老师和学生,有些是专业开发人员… 很多用户对它也有很多改进意见, 那我们到底为哪些用户服务呢?
同时,VS的微软团队也有很多开发人员,他们也是用户,只听取他们的意见是不是就够了呢?
在开发一个新版本的VisualStudio时候，如果你来主持需求分析工作,你的工作结果会指导上千名工程师,UI设计师,PM,市场推广人员未来两年的工作。
你怎么办?
[给大家10分钟讨论]
下面是微软在VisualStudio2005设计阶段使用的几个典型用户（persona）:
典型用户
造型
Personadetails
特点
Mort
Mort,theopportunisticdeveloper,likestocreatequick-workingsolutionsforimmediateproblemsandfocusesonproductivityandlearnasneeded.
Mortissomeonewhodoesn'tconsiderprogrammingtheirmainjob.Maybetheyareastatistician,biologist,orconstructionestimator,whoalsoknowsquiteabitaboutprogramming.Theyareopportunistic,usingwhatevertoolcomestohandthatwillgetthejobdone.
不一定是专业出身的程序员, 他们有自己的主业, 编程只是一个工具,他们的主要目的就是用工具把事情搞定就行了。
他们很喜欢代码示例,也不特别关心程序效能。
（例如许多VB用户,偶尔用VS写程序处理数据的研究人员等）
Elvis
Elvis thepragmaticprogrammer,likestocreatelong-lastingsolutionsaddressingtheproblemdomain,andlearningwhileworkingonthesolution.
Elvis:
journeymandeveloper.
Youcanscopeoutajobandgiveittothem,andthejobwillgetdone.Ingeneral,Mortsdon'tbecomeElvises.Mortswanttodotheirmainjob;theydon'tWANTtobecomeaprofessionaldeveloper. ElvisesgotoschoolandgetCSdegrees.
以编程为生的程序员, 他们大多是CS专业出身。
各种IT公司的开发人员应该是在这一类中。
Einstein
Einstein,theparanoidprogrammer,likestocreatethemostefficientsolutiontoagivenproblem,andtypicallylearninadvancebeforeworkingonthesolution.
EinsteinisasmartElviswhohaslotsofexperience.
Einsteincanseethebigpicture.AnEinsteinoftenisinapositionofresponsibility,choosingtechnologiesanddesigninglargesoftwaresystems.
在行业里战斗了很多年的程序员,架构师,项目经理。
他们能决定项目用什么样的技术以及发展路线。
这里有一些网上关于VS各种典型用户的评论。
我在移山之道里也举了一些和中国程序员较接近的例子[移山之道第14章]
14.1 典型用户
大牛和小飞在讨论网站界面的时候吵了起来。
大牛：
这个界面对于一般用户来说太复杂了。
一般人根本搞不懂。
小飞：
我们这个界面是针对有很多经验的用户，就像卖石头的吴石头，他搞石头生意有那么些年了，他应该对我们用的术语比较熟悉，而且会用电脑，我们并不针对初次使用我们系统的用户，或者对奇石生意有了解，但是对电脑一窍不通的人，就像石头他爹。
大牛：
不对，我们要针对那些对奇石生意有了解，但是对电脑一窍不通的人，我们有一些功能是为这些用户设计的。
小飞：
不对，我们主要的用户是对石头生意很了解，并且对电脑的使用很熟悉的人。
而且这也符合所谓“Persona”的要求。
大牛：
我不管你的“Person-a”，我们要分析用户的需求，在把需求搞清楚之前，管他“Person-a”还是“Person-b”，都没有用。
我们还是不要用这些名词忽悠我们自己。
他们俩一起来到阿超面前，把事情原委说了一遍。
阿超：
所谓“Persona”，就是典型用户，吴石头/石头他爹就是我们系统的两个典型用户。
我们的确要了解我们软件系统的用户（不是公司的商业客户），那么，什么是典型用户？
在产品开发的过程中，我们经常需要描述一组典型的用户。
以前大家通常是以一些抽象的名词来表示，如“家用电脑初学者”，“经验丰富的系统管理员”，现在我们建议用一个“典型用户”来代表。
典型用户不再是一个抽象的概念，而应该是一个活生生的人物。
典型用户有哪些特性?
一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
大牛：
以前我们管台风叫1号、2号，现在都起了名字，叫云娜、海棠、卡特丽娜、桑迪，等等，是不是跟MSF-Agile学的？
阿超：
这你得问气象部门，至少台风“海棠”比单纯的数字好记。
但是我们的Persona还包括了更多的特性，不光光只是一个代号，一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
在别的行业中可以用到Persona的设计方法。
我今天去银行开账户。
开完账户后，服务生在窗口后低着头，过一会看我还坐着，就说，没事了，你可以走了。
我还想了解一些其他的服务，比如信用卡/理财账户，等等，她好像对此没有兴趣。
看起来银行把我的“开户”处理成一个单独的事件，开了账户就完了。
如果银行分析开户人的Persona，它可能了解一些典型用户的典型心理，比如小企业主崔大智来开户，他就是来开个户就完了？
当然不是！
他有不少钱，可能申请信用卡、建立理财计划、贷款、联系代发工资，等等。
如果银行仅仅帮他开个户就把他打发走了，那样失去了多少商机？
！
在设计软件的过程中，我们（设计/开发者）往往会以我们使用产品的习惯和我们对产品的熟悉程度出发设计，忘了我们的软件是给千千万万个不那么会用电脑的人使用的。
在这种情况下，搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。
大牛：
阿超刚才提到别的行业，我想起一个例子，两年前俺们村接待了国外的投资参观团，我临时被抓过去作翻译。
村长和支书兴冲冲地带领他们参观了王屋村的产值大户——小化工厂和烟花爆竹厂。
他们带领客人穿过粉尘弥漫的化工厂车间，弄得老外咳嗽不止。
在车间外，大家看到没有处理的污水直接排放到王屋河中；到了烟花爆竹厂，大家看到数十名没有任何安全保护的女工在安装各式烟花，空气中不用说有硫磺和其他化合物的味道。
参观团的团员们发出了介于惊讶和恐惧之间的评价，我很难翻译成中文。
参观团走后就杳无音信了。
如果分析客户的情况，从客户角度出发，就会发现他们是想来开发这一带的以历史传说为背景的人文旅游资源，他们想看到的是未被污染的风景——王屋河的上游有不少，还有淳朴农家的生活方式，我们也有，当然支书家的生活方式已经不能用“淳朴”来形容。
可惜我们没有让客户看到他们想要的东西。
小飞：
对呀，去支书家可以看到资产阶级的生活方式，我目前没有搞懂的是他家是小资还是大资。
14.1.1 怎样定义典型用户
怎样才能定义典型用户呢？
我们首先要定义用户的角色。
正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。
如果用户有不同的安全需求，切记要定义不同的角色来适应这些需求。
如下面的例子：
◆ 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”；
◆ 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的。
Persona可以包括以下内容：
（1）名字（越自然越好）。
（2）年龄（不同年龄和收入的用户有不同的需求）。
（3）收入。
（4）代表的用户在市场上的比例和重要性（比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要）。
（5）使用这个软件的典型场景。
（6）使用本软件/服务的环境（在办公室/家里/沙发/床上/公共汽车/地铁…）。
（7）生活/工作情况。
（8）知识层次和能力（教育程度，对电脑、万维网的熟悉程度）。
（9）用户的动机、目的和困难（困难 = 需要解决的问题）。
（10）用户的偏好。
我们的软件不是为所有人服务的。
问：
那这样不就是损失了大量潜在的用户，我们至少得争取一下为所有人服务，如果不行，再回到少部分用户？
答：
不妥，我们宁可从小部分人出发，要非常明确地定义谁是我们的用户。
回过头来看，Stone 网站有什么基本角色呢？
大家杂曰——
（1）商户：
在网站上出售货物的用户。
（2）买家：
在网站上购买货物的用户。
（3）浏览者：
在网站上浏览，并比较货物，并不购买。
（4）广告商：
在网上卖广告，这些角色可能不会直接使用网站的用户界面。
（5）管理员：
管理网站。
（6）捣乱者：
想入侵网站，窃取资料，在留言中发未经许可的广告，搞人身攻击等。
在TFS项目的门户网站中有定义典型用户的模板（路径一般是<网站名>Requirements/Persona.doc）。
可以用作参考。
在大牛和芸芸的带领下，大家整理出来了下面几个典型用户，如表14-1至表14-6所示。
表14-1 吴石头——下水捞石头的人
名字
吴石头
性别、年龄
男，45岁
职业
经营石头生意
收入
10万元/年
知识层次和能力
初中毕业，用电脑只会玩简单的游戏
生活/工作情况
通过卖石头，在王屋村有自己的房子
动机，目的，困难
结识更多买家，扩大销路，争取卖个好价钱，给孩子盖房娶媳妇。
困难：
不知道怎么去扩大销路
用户偏好
抽烟，晒太阳
用户比例
？
典型场景
他从河里挖出一块石头之后，要把这块石头的信息弄到网上去
典型描述
石头越捞越多，钱越赚越少
表14-2吴小石头——让石头上了网
名字
吴小石头
性别、年龄
男，20岁
职业
帮他爹做石头生意
收入
目前都上交给他爹
知识层次和能力
河曲村农机技校毕业，能用电脑上网、聊天、游戏
生活/工作情况
帮他爹做石头生意，平时在顶球网吧
动机，目的，困难
希望早日盖房，独立。
困难：
要扩大销路，让更多的人知道我的石头
用户偏好
上网，游戏，交友
用户比例
？
典型场景
回答买家问题，更新产品资料
典型描述
我不在顶球，就在去顶球的路上
表14-3 刘兰——上网捞石头的人，一般浏览及购买的用户
名字
刘兰
性别、年龄
女，永远28岁
职业
金融公司管理人员
收入
20万元/年
知识层次和能力
大学，MBA，每天和电脑、数字打交道
生活/工作情况
职业有上升空间，目前享受独身乐趣
动机，目的，困难
工作累，以收集小玩意儿为乐趣。
困难：
很难找到真正有乡土气息的工艺品
用户偏好
看得多，买得少
用户比例
？
典型场景
浏览各种货物
典型描述
白骨精——白领，骨干，精英
表14-4 钱炎凯——撒网大量收购石头的人——买家，二道贩子，
鉴赏家，广告商
名字
钱炎凯
性别、年龄
男，40岁
职业
石头、古玩、工艺品经销商
收入
30万元/年
知识层次和能力
大学，能用电脑上网、发邮件。
不玩游戏。
委托别人设计了自己的网站
生活/工作情况
在商店/外地来回跑，已婚
动机，目的，困难
要搜罗更多有独特价值的工艺品。
困难：
很多好东西都在深山老林里，不易发现；要让更多的人知道我自己的网站
用户偏好
下手狠，喜欢独特的货品
用户比例
？
典型场景
比较各种货物
典型描述
货比三家，我家最好
表14-5 捣蛋鬼阿狗
名字
阿狗
性别、年龄
男，20岁
职业
某软件学院学生
收入
无正式收入
知识层次和能力
大学
生活/工作情况
从小用电脑，有很多业余时间上网捣乱
动机，目的，困难
看看能否进到管理员账户
用户偏好
喜欢没有密码的用户
用户比例
？
典型场景
访问“登录”，“忘记密码”网页
典型描述
没有我黑不了的网站
表14-6网管阿毛
名字
阿毛
性别、年龄
男，20岁
职业
某软件学院学生，兼职stone 网站网管
收入
实习生
知识层次和能力
大学
生活/工作情况
从小用电脑
动机，目的，困难
维护网站，最好什么乱子都没有。
困难：
最恨界面不统一
用户偏好
喜欢简单易管理的网站
用户比例
相当少，只有3~4名
典型场景
删除帖子，管理用户，分析访问数据
典型描述
本网站不欢迎黑客
定义了最初的Persona之后，是不是就可以开始写程序了？
不，Persona只是我们的设想，这些都是纸上谈兵，我们还要和这些Persona的代表交流，理解用户，理解他们的工作方式和需要。
然后再修改，细化Persona。
于是移山公司的员工和实习生花了几天时间，做了不少用户调查，搞了不少头脑风暴，画了无数草图。
芸芸：
（回来报告）除了进一步了解用户的需求，细化了一些功能的设想外，我们还有一个重大发现，我们的第一个典型用户，吴石头，好像不喜欢上网，他事实上不太会用电脑，也搞不懂如何上传照片。
凡是和网络相关的事情，都交给了他的儿子。
所以我们不得不把吴石头从典型用户中删除。
大牛：
吴石头，再见了！
芸芸：
我们花了好多时间，结果精心打造的Persona却被取消了。
伤心哪！
阿超：
不必这么伤心，越早发现问题，越早解决，不是更好么？
如果我们一意孤行，一直为“吴石头”设计功能，最后却发现众多的“吴石头”却不能使用我们的软件，那岂不是更糟糕？
当我们完善了典型用户的定义后，就要讲一些他们的故事,进入“创立场景”阶段——创立场景就是我们深入理解用户需求的过程。
14.2 从典型用户到场景
有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的（如：
购物者，产品提供商，滥发广告者……）对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事/Story。
注意，有些场景描述了成功的结果，有些场景描述了失败的结果。
用户和系统有成百上千种可能的交互情况，在写场景的时候要有针对性。
这是一个现实生活中银行从业者的微博，他体会了“ATM无卡取现”功能的强大:
特意带上手机和令牌不带卡，感受一下我行ATM的无卡取现，结果连自助银行的门儿都没进去，不刷卡怎么开门啊。
。
。
。
如果这一重要功能的设计者在需求分析的时候就模仿用户,设计场景,演一个戏.也许很快就发现戏演不下去了。
场景怎么写?
对每一个场景，设计一个场景入口（描述场景如何开始）。
描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）。
给场景划分优先级，就按优先级排序。
写场景（总得有人动笔写）。
这一任务就由PM芸芸来负责，下面是她写的一个一页场景。
场景 移山公司文档 [http:
//www.yishan.cc]
工作项序号128：
商户上货，最后修改时间：
2007/3/1
1．背景：
（1）典型用户：
吴小石头[主要] 刘兰[次要]
（2）用户的需求/迫切需要解决的问题
a．吴小石头：
上货过程冗长，要反复输入相似的文字，出错之后不容易恢复。
b．吴小石头：
上传图像文件较慢，各个图像的标定（正面，侧面，缩略图）较繁琐。
c．吴小石头：
上货完成后，最后的商品信息展示的整体效果事先不能知道。
还要手工标注哪些是新产品，哪些是老产品。
（3）假设：
a．商品信息展示功能已经完成。
b．用户订阅某个商家的产品更新功能已完成。
2．场景：
关于这个场景的文字描述。
吴小石头要把最近处理好的两个石头工艺品放到网上去卖。
他先登录Stone网站，如果他设置了“记住我的登录资料”，Stone网站会自动登录。
他点击“上传产品信息”，然后就进入了上传页面。
页面中各个字段的布局和最终用户看到的一样，这样他在编辑的时间就知道效果了。
他可以选择先上传图像文件，网页可以自动开始后台处理图像文件的上传，这样当他处理网页其他资料的时候，图像也上传得差不多了。
他依次输入商品的名字、描述等。
网页自动记住了他以前输入的资料，在各个字段中都有提示，他一般选中以前的输入，然后稍作修改即可。
他输入完必须填写的资料后，就可以选择下面三个动作之一：
a．立即发布；
b．保存，不发布；
c．保存，继续编辑。
选项c的作用是让他保存好已经输入的信息，不至于因为网络连接中断等原因而丢失。
选项b让他可以保存资料，但是不立即发布。
选项a让他可以立即发布商品信息。
这次，吴小石头选择a，网页会检查输入的完整性，必要时给予提示。
所有资料上传到网站后，网站会自动生成上传图像的各种缩略图（64×64、128×128、512×512等），自动把这一产品标注为“新产品”。
系统同时根据规则（每个商户只能有10个新产品）把以前商品的“新产品”标注去掉。
吴小石头在完成这一操作后，如果用户刘兰订阅了商户“吴小石头”的产品更新，刘兰就会收到一份E-mail，告知她喜欢的商家又有新产品上市了。
3．其他资料
（1）商户登录网站场景参见TFS任务121。
（2）商品展示场景参见TFS任务122。
场景之间如何区分呢，这就要求我们要找到这个场景中特殊的地方，对于共同的流程可以一笔带过，重点描述场景中特殊的因素。
把场景组织成一个故事，这样就能把一个完整的用户与系统交互的流程记录下来，以后进行演示或验收都可以以此为基础。
场景设计听起来这么好，但是做过了头会是什么情况？
一天，大家在讨论“吴小石头上货”这一场景时，二柱叫到：
“停，别忙了，我有了场景！
”他从桌子底下抽出一个模型，上面摆着用纸糊起来的房子、院子等，中间有几个人形的木头疙瘩，他指着其中一个木头疙瘩说，“这就是吴小石头，我们问他怎么做就行了！
”
14.3 场景到任务
有了场景，下面就由架构设计师和各个模块的负责人一起，沿着子系统/模块的所属关系把场景划分开。
例如Stone项目的用户登录场景，就可以分为：
（1）UI层。
子任务为：
界面设计，货物资料处理，文件上传处理，编辑控件等。
（2）逻辑层。
子任务为：
用户输入字段合法性处理，上传图像逻辑和缩略图处理，资料保存逻辑等。
（3）数据库。
子任务为：
资料读取的存储过程，图像的索引建立和维护等。
不同的任务把一个场景编织起来，虽然有多个开发者参与这个工作，但是应该有一个开发者对整个场景负责，我们得到了开发任务之后，就可以创建和分配测试任务。
14.4 从任务到代码
14.4.1 接到任务
小飞接到任务后，他会怎么办呢？
他会做下面这几件事情。
（1）估计开发任务所需的时间，他会参考以前同类任务所需花费的实际时间，以及别的同事的时间估计。
（2）小飞会试着写一些快速原型的代码，看看效果会怎样。
他在这一过程中发现了一些问题，通过和PM沟通，他们取得了一致意见。
（3）在看到初始效果和了解了实现的细节后，小飞开始写设计文档，写好之后，他可以请同事一起来复审设计文档（复审可选，因为一般情况下任务都不大）。
（4）设计文档写好之后，小飞就会按照设计文档写代码。
在写的过程中，他又发现了一些原来没有想到的问题，通过和PM沟通，找到了解决方案。
（5）写好代码后，小飞对照设计文档和代码的指南作自我复审。
（6）创建或更新单元测试。
（7）进行单元测试（不仅要通过自己新创建或更新的单元测试，还要通过整个模块/系统的单元测试）。
（8）重构代码，如果必要的话。
（9）代码复审。
（10）把代码签入代码库中。
由上可知，开发者必须写自己代码的单元测试。
开发环境必须能够很快地让一些小的修改通过（做一个代码修改的最低成本是多少？
例如，如果我只改动一个无关紧要的功能，要多长时间才能运行所有的单元测试。
要求：
快速，自动化）。
14.4.2 把修改集集成到代码库中
现在开发人员手头上有不少修改，分别属于不同的具体任务，那如何把这些修改签入源代码控制之中呢？
（1）根据场景和开发任务来决定集成的次序。
（2）互相依赖的任务要一起集成。
（3）在测试场景时，要保证端到端的测试。
（4）场景的所有者必须保证场景完全通过测试，然后把场景的状态改为“解决”。
14.4.3 标准开发人员的工作流程
综上所述，我们就可以得到开发人员的工作流程（如图14-1所
升级会员 