Lab 5：面对面需求获取与原型设计

1. 实验要求

练习面对面交流的方式进行需求获取，澄清用户需求

根据用户需求建立用户故事清单，使用敏捷开发方法为用户故事建模卡片，规划优先级，估计工作量，构思迭代计划

练习使用VersionOne或其他自选的Scrum项目管理工具为项目建立Scrum迭代计划

练习使用MockupBuilder或其他自选的原型设计工具为每个用户故事设计原型

练习用户评审

1. 面对面需求获取

1. 项目概述

本组项目：

项目名称：学术师承树

目标用户：拥有学生或者老师身份的人

系统核心价值：由师生关系与师兄弟关系建立起的学术关系树

每个用户可以构建自己的学术师承树，自己的树也可以与其他人的树进行连接生成更大的树，用户可以查看或者修改自己或者别人的关系树，同时还可以查看相关用户的信息

对方组项目：

简要介绍对方组3人所面对的实践项目的基本情况（名称、目标用户、系统核心价值等）；

名称：学术日历与学术地图
目标用户：关注学术会议的各领域学术人士
系统核心价值：为用户提供学术会议的第一手信息的手机App
该项目主要实现四个功能：
1.汇集历史学术会议举行的时间、地点、主题、URL、deadline
2.实现用户手工输入个人会议日程
3.用户提供某个学术领域关键词，系统检索相应的学术会议列表，将日程更新至用户的Google Calendar（或其他web日历、手机日历），通过Google地图（或其他地图）展示选定的会议地点；
4.用户可关注若干会议，系统自动为其做出各个deadline的提醒。

1. 预设计的问题清单（本组作为开发者角色）

给出本组人员在问答之前所设计的一组问题（请根据需要增加下表的行），请按照优先级从高到低排序，目标是通过询问这些问题，澄清本组人员对自己的实践项目的需求。

问题编号	问题描述	询问该问题的目的（试图希望客户澄清的内容）
	用户在构建与修改的时候每一条边都是随意的吗？	明确每个用户对于边的构建与修改的权限
	用户的信息必须要包含的内容有什么？	明确用户信息
	用户没有LinkedIn与Google Scholar时需要用什么来代替？	明确用户想要展示的个人信息内容
	对于界面有什么特定的要求吗？	明确用户对于界面的要求

1. Q&A过程（本组作为开发者角色）

记录本组（扮演开发者）和对方组（扮演客户）进行面对面需求获取问答过程中的问题和答复情况。

每个小组在Q&A过程中务必保证有一人进行记录，或者使用录音笔录音，事后整理成下表。请根据实际问答情况增加下表的行数。

本组所提问题	对方的回答	所用时长（分钟）
当别人要修改你的个人师承树时你希望如何处理？	最好有一个修改请求，比如他要将我加入到他的师承树上作为他的师傅，那我这边就会收到一个提示，我如果通过了他的验证，那么在整体的大树上就会添加上我们两个的师徒或师兄弟关系，我自己的个人树上也会添加这个人。如果我没有通过验证的话，那么他的个人树上与我的连线就要显示未验证，而我的个人树和整体的大树上将不会添加我们两个人的关系。	11
如果出现你添加的与你有关系的人不是我们这个网页的用户怎么办？	我首先需要确保这个人的名字可以显示在我个人的师承树上，至于你们如何处理这个用户的信息，是直接新建一个信息不全的人的名片啊，还是只显示名字，由你们决定。	5
您希望显示的个人信息都包括什么？	姓名 性别 电话号码 邮箱 毕业院校 工作单位 CSDN博客主页，最重要的是最好有我可以联系上他的联系方式。	4
如果出现重名您希望如何处理？	可以从一开始就禁止重名，比如新建用户时如果有重名就属于非法输入，需要在后面加上数字，比如张三1，张三2。或者你把他们的姓名以及其他信息都列出来，在别人检索这个名字的时候，由用户根据第二关键词选择准确的人。	7
对于个人树您希望以一个什么方式呈现？这棵树的深度显示到哪个地步合适？还有关于时间比如从小学到大学各个时间阶段？	我希望最好可以实现一个图形可视化，比如我的这个节点是一个圆圈，里面有我的头像和名字，然后和我联系的人也是一样。最好我和联系人的箭头上标注他是我什么时间段的什么人。 然后树的深度显示到与我直接相关的二级师生关系就可以。 点击节点可以直接显示这个人的详细信息以及他的个人树。	10
个人树的时间属性您是希望可以有那种按钮点击各个学术阶段，比如高中，大学这种；还是希望可以有一个检索年份的功能？	在我与联系人关联的箭头上标注时间属性，比如你说的学术阶段，最好是可以检索年份，指定年份的个人树，如果没有检索的话就显示最近的默认个人师承树就可以。	5
如果他人要删除您个人树的信息您希望如何处理？	还是以提出申请的方式，如果我同意就可以删除，大树上也删除我们的关系。	3
任务繁杂，您希望我们最优先实现的功能有哪些？	1）确保我能建立起个人师承树，这棵树在别人点击进我的个人主页时可以看到，不管验证不验证。 2）确保我可以点击链接进入他人主页，获取到他人联系信息。	5

1. 用户故事

针对Q&A之后澄清的需求，分析用户故事。

1. 用户故事清单及优先级

根据需要增加下表的行。

按照优先级排列用户故事，排在上面的用户故事具有更高的优先级。

用户故事编号	用户故事简称	用户故事描述	优先级估算（采用5、4、3、2、1的方式，数字越大表示优先级越高）
	添加详细信息	作为一个本科生，我希望他人的详细信息可以包括联系方式，这样我可以直接联系到师兄弟或者老师请教。	4
	查看主页	查看别人的主页，这样就可以知道哪个老师会有较大的可能带我这样的学生。	2
	建立二级树	作为一个本科生老师，我希望可以建立起自己可见的与我二级有关的学术师承树，这样别人点进我的主页的时候就可以看到我都教过哪些学生。	5
	建立页面人员链接	作为一个在企业工作的在职人员，我希望可以建立起页面的人员链接，这样我可以通过师承树收获更多人脉。	2
	增添链接的时间属性	作为一个在全国五百强工作的职员，我希望可以增添链接的时间属性，这样便于我可以在企业中找到我的校友。	2
	修改树时要有确认信息	作为一个教授，我希望别人在修改我的个人师承树时我这里会收到验证确认，这样确保没有学生谎称我是她／他的老师，提高整体师承树的权威性和可信度。	3

1. 用户故事1

使用卡片图形的形式，描述每个用户故事。

• 正面：文字描述（作为一个<角色>, 我想要<活动>, 以便于<商业价值>）、简要的示意图；

作为一个本科生，我希望他人的详细信息可以包括联系方式，这样我可以直接联系 到师兄弟或者老师请教。

• 反面：确认信息（该用户故事执行成功后的结果、各种执行失败情况后的结果）

成功：显示全部联系方式；

      新建的联系方式 已保存；

失败：该用户未存储过联系方式；

  该用户非本网站用户。

1. 用户故事2

使用卡片图形的形式，描述每个用户故事。

• 正面：文字描述（作为一个<角色>, 我想要<活动>, 以便于<商业价值>）、简要的示意图；

作为一个研究生，我希望可以查看别人的主页，这样我就可以知道哪个老师会有较 大的可能带我这样的学生。

• 反面：确认信息（该用户故事执行成功后的结果、各种执行失败情况后的结果）

成功：显示主页，主页内容包括个人信息以及个人学术师承树

失败：该用户未更新过师承树信息

1. 用户故事3

使用卡片图形的形式，描述每个用户故事。

• 正面：文字描述（作为一个<角色>, 我想要<活动>, 以便于<商业价值>）、简要的示意图；

作为一个本科生老师，我希望可以建立起自己可见的与我二级有关的学术师承树， 这样别人点进我的主页的时候就可以看到我都教过哪些学生。

• 反面：确认信息（该用户故事执行成功后的结果、各种执行失败情况后的结果）

成功：显示与本人相关的二级有关学术师承树

失败：该用户的一级关系人与二级关系人关系未通过验证

  该用户的一级关系人未通过该用户验证请求

1. 用户故事4

使用卡片图形的形式，描述每个用户故事。

• 正面：文字描述（作为一个<角色>, 我想要<活动>, 以便于<商业价值>）、简要的示意图；

作为一个在企业工作的在职人员，我希望可以建立起页面的人员链接，这样我可以 通过师承树收获更多人脉。

• 反面：确认信息（该用户故事执行成功后的结果、各种执行失败情况后的结果）

成功：可以在一个用户界面通过点击该用户关系人名字直接进入关系人界面

失败：无法循环链接

  出现无效或不存在或非法用户

1. 用户故事5

使用卡片图形的形式，描述每个用户故事。

• 正面：文字描述（作为一个<角色>, 我想要<活动>, 以便于<商业价值>）、简要的示意图；

作为一个在全国五百强工作的职员，我希望可以增添链接的时间属性，这样便于我 可以在企业中找到我的校友。

• 反面：确认信息（该用户故事执行成功后的结果、各种执行失败情况后的结果）

成功：通过检索年份自动重新生成该年份下该用户的学术师承树

失败：该年份该用户暂无学术师承树信息

  无法确定该年份是开始年份还是截止年份

1. 用户故事6

使用卡片图形的形式，描述每个用户故事。

• 正面：文字描述（作为一个<角色>, 我想要<活动>, 以便于<商业价值>）、简要的示意图；

作为一个教授，我希望别人在修改我的个人师承树时我这里会收到验证确认，这样 确保没有学生谎称我是她／他的老师，提高整体师承树的权威性和可信度。 

• 反面：确认信息（该用户故事执行成功后的结果、各种执行失败情况后的结果）

成功：每当别人要增添，修改，删除该用户的个人师承树时，该用户都会收到验证 请求，如果点击通过，那么在整体的内部师承树以及此二人的个人师承树上面就会 增添这两个人的信息，如果点击拒绝，那么以上都不会呈现。

失败：某用户发送了错误的请求无法撤回，而且对方错误的点击了通过。

1. 用户故事的工作量估算

针对识别出的每一个故事，使用Story Point估算其工作量，工作量的单位是天。

使用预定的值：1/2、1、2、3、5、8、13、20，单位为“小时”；

团队成员分别估计，差异较大时面对面讨论，发现分歧，形成共识。

填写下列表格（表格里给出了三轮，若第一轮就达成共识或者估算差异不大，就不需要进入第二轮，依此类推；最后一列是大家最终达成的共识）。

故事编号	故事简称	小组成员对其工作量估算									最终估算
		第一轮			第二轮			第三轮
	添加详细信息	1	1	1							1
	查看主页	4	5	5							5
	建立二级树	8	7	3	6	6	5				6
	建立页面人员链接	8	4	5	8	7	8				8
	增添链接的时间属性	6	7	6							6
	修改树时要有确认信息	9	10	8	8	9	8				8

1. 迭代计划

若本项目采用三次迭代，根据各用户故事的优先级和工作量估算，将用户故事分配到各次迭代当中，计算各次迭代的总工作量。确保这样的安排符合3.2节给出的依赖关系和优先级安排，以及各次迭代的总工作量的平衡。

• 第一次迭代：9月21日——11月15日
• 第二次迭代：11月15日——12月13日
• 第三次迭代：12月13日——本学期期末

请根据需要增加下表中的行数，但不能增加迭代次数。

迭代次数	包含的用户故事	故事的优先级	故事的工作量估计	计划起止时间	本次迭代的总工作量
1	添加详细信息	4	1	9.22--9.23	13
	设计登录界面	3	1	9.25--9.26
	建立二级树	5	6	10.10--10.16
	查看主页	2	5	11.01--11.06
2	建立二级树	5	6	11.16--11.22	22
	建立页面的人员链接	2	8	11.25--12.03
	修改树时确认信息	3	8	12.05--12.12
3	添加链接的时间属性	2	8	12.14--12.22	15
	完善以前实现的功能	--	7	12.23--12.30

1. 使用VersionOne或其他工具管理用户故事和迭代计划（选做）

根据第3、4、5各部分的内容，使用VersionOne或其他Scrum项目管理工具建立你们的项目管理计划，将结果以截图的形式放在此处。

1. 建立团队、项目、成员
2. Product Backlog（全部用户故事）
3. Sprint Planning（规划迭代）

应包含至少两次迭代的计划

1. 形成每个Sprint的Story Board

应表征出项目开发的当前进展情况

1. 形成每个Sprint的Burndown Chart

应表征出项目开发的当前进展情况

1. 原型设计

针对3.1节识别出的每个用户故事，使用MockupBuilder或其他原型设计工具建立其原型，将原型截图放在以下各小节里。

1. 用户故事1

1. 用户故事2

1. 用户故事3

1. 用户故事4

1. 用户故事5

1. 用户故事6

8需求评审

列出对方小组（扮演用户）对本组需求获取结果review之后给出的反馈意见，并阐述本组如何响应每条意见、具体做了哪些调整。

注：对方小组的review意见，此处应给出对方小组发送给本组成员的Email截图。如果是双方面对面进行review，需给出具体的时间、地点、当时的工作照片。

1.可视图最好要有，这样更方便查找相关的人，列表的话层级关系不直观

对于可视图的实现会尽量做到，尽力而为。。。

2.查找其他人时给出的关系树要显示那个总树，个人树要由单独的链接查看

在查找某人显示该人的关系树的时候，我们要从总树的信息中提取关于这个人的关系的三层树进行显示，再显示下关于这个人自己构建的树

3.时间戳相比认证关系更重要，添加认证可以有，也很好，但其他用户在查找关系时应该更关注有效信息而不是认证与否（因为他也不知道对错），所以关系的时间戳要注意

时间关系一定要严格遵守，不显示已经不存在了的关系，关于认证部分的实现可以暂时作为附加要求

4.关于总树的问题，应该更注重信息量方面而不是准确度，所以要显示尽可能多的信息（未认证的最好也添加）

关于认证的问题可以在具体的实现过程以及日后的使用过程中考虑是否必要，未经认证的信息也要加入到总树中并在搜索时予以显示

截图：

这是聊天记录截图的一部分。。。

9计划与实际进度

任务名称	计划时间长度（分钟）	实际耗费时间（分钟）	提前或延期的原因分析
Q&A	60	70	关于有些问题的解决方案讨论的时间略长
用户故事	300	360	第一次编写在语言与界面上的设计都花了很长的时间
迭代计划与工作量估计	90	120	关于迭代计划我们讨论了很久，因为有些地方还未进行深入的学习不是特别的清楚到底该分配多少时间
原型设计	40	50	用户故事绘制比较费事
需求Review	40	50	关于用户提出的某些问题在修改意见上与用户进行了很长时间的沟通

10小结

• 你认为面对面的需求获取是否可帮助开发者澄清用户需求？

我认为这是非常有必要的，不管是对于开发者还是用户，面对面的交流可以使双方在交流的过程中发现一些自己本来没有注意到的问题，这样子有助于更好的实现贴近用户需求的产品

• 在面对面需求获取时，你是否总结出恰当的策略，可以与用户进行高效率的沟通？在该过程中，你们收获了什么经验与教训？

在与客户交谈的过程中，可以基于自己的专业知识来为客户提出相应的建议，对于客户的要求要认真聆听同时认真思考这个过程中会出现的一部分问题及时询问清楚。在这个过程中我觉得理解客户的要求真的是很重要的，因为每个人的想法都不尽相同，尤其是关于一些抽象东西的理解。

• 请给扮演你们系统的用户角色的另外一组学生在Q&A过程中的表现打分（该分数只是给教师/TA看，不会暴露给对方），并简要描述他们提供的信息对你们进行需求理解产生了什么积极作用。

如果10分为满分那么我们的客户小组可以得到8.5分，因为专业知识比较丰富，他想问题的时候会关注一些我们不太会注意到的问题，例如他对于关于建树过程中的征求对方同意这个问题的提出就让我们对于这个项目的某些地方有了新的理解。

• 你们小组三人如何协作完成用户故事的优先级指定和工作量规划？有何经验与教训？

关于用户故事的优先级指定我们只是觉得要将基础的功能放在首要的位置上，对于工作量规划的问题我觉得不做的话很难准确的估计，我们只是靠着自己的了解大致估算了一下时间，估计还是会与实际有很大的冲突。

• 设计原型会对实践项目的开发带来什么有益的帮助？你们体验到了吗？

我们体验到了设计原型对实践项目开发带来的很大的帮助，设计原型有助于项目敏捷开发的完善。在原型设计过程中我们发现，项目的开发和原型的设计是相辅相成的。首先，项目设计决定了软件最后的状态，反过来，原型的设计对项目的开发起到了启发的作用 。

• 从本次实验获得的其他收获。

整个实验过程中我们感受到了与以前只是按照老师的要求埋头写代码完全不一样的东西，在交流中澄清用户需求是一个很难的过程，现在做的毕竟是一个项目，关于某些功能该有的限制非常的多，在与扮演用户的组进行交流的过程中弥补了很多我们对于项目需求认识的漏洞，有助于我们更好的实现项目。还有就是原型设计部分，