《用户故事与敏捷方法》阅读笔记04

第五章与用户代理合作
      由于有些时候不能和实际用户一起工作,所以我们要向用户代理求助。用户代理不是真正的用户但是在项目中代表着用户。用户代理分为几种。第一种用户的经理,经理往往并不真正知道实际用户的需求,提出的需求可能只考虑到自己的需求,但是这些需求功能却很少被用到。甚至有时候经理或从中干预,并且固执的认为自己可以更了解自己的用户的需求。这时,在不得罪经理的情况下,要想办法接近终端用户。第二种是开发经理,这是最坏的选择之一,因为他的目标和实际用户的目标可能相冲突。第三种销售人员,这也是危险的选择,因为他所注意的是导致他丢单的故事,但是过分关注每个丢单的故事会使产品的远景停止不前。第四种是领域专家,这是非常重要的资源,他们对软件应用的了解对开发有着关键影响。如果他们用过或者正在用类似的软件,那么他会对你非常有帮助。第五种是市场营销团队,他们可以为相关故事的优先级提供高层次的指导意见,但是由于他们不具有良好的洞察力所以不能提供细节。第六种以前的用户。第七种是客户,出钱的人,他们不一定是用户,所以他们的意见和用户的意见可能不一致。第八种培训师和技术支持,培训师会偏于培训,技术支持会偏于技术。第九种业务分析师或系统分析师,他是和好的用户代理,因为他们即懂技术又懂领域知识,但是有时会空想,而不调查。
  在和用户代理合作时,如果能接触到用户,但是访问受限时,可以请求一个用户顾问团队,但是项目的最终决策者还是用户代理。如果不能接触到用户,可以使用多个用户代理。任何时候实际用户总是优于用户代理的,尽量邀请真实的用户加入,加入后,设立项目负责人,将所有的客户声音集中起来,最后要确定项目成功的关键因素。

时间: 2024-08-27 01:34:59

《用户故事与敏捷方法》阅读笔记04的相关文章

《掌握需求过程》阅读笔记04

<掌握需求过程>阅读笔记04 我们在开发我们的系统的时候要是要给用户用使用的,所以用户的使用感受非常重要,这就需要我们站在用户的角度去考虑这个系统如何让用户的使用更加的简捷,而不是站在你开发者的角度去考虑这个系统如何开发比较省我自己的事儿.抱着多一事不如少一事的态度开发出的系统是我们懒惰情况下的残次品,是注定要被淘汰的,而我们也可能因为这样的态度,面临我们的工作也将被人这样轻视.要把握好用户的使用习惯.操作环境,就需要我们去体会用户的使用感受,就需要我们具有同理心. 编写用户故事.我们可以把我

《用户故事与敏捷开发》阅读笔记04

  <用户故事与敏捷开发>阅读笔记04 今天抽出了两个小时读了<用户故事与敏捷开发>的第十二.十三.十四以及十五章并写了这篇阅读笔记.第十二章标题为"故事不是什么".IEEE 830是一本关于如何编写软件需求规格的指南,最突出的特征是使用短语"系统应该.....",但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务.因为用户看到正在开发的软件时总会有有效和重要的反馈循环.他们会改变之前的想法,而且每个需求的成本是不可见的,会造成分析

UML大战需求分析——阅读笔记04

读<UML大战需求分析>有感04 开发某系统的重要前提是: 这个系统有谁在用? 这些人通过这个系统能做什么事? 一般搞清楚这件事,再画个业务流程图,就能条例清楚的表达系统的需求了.作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙. 用例图是用处非常广泛,使用频率最高的UML图,它用来描述什么角色通过某某系统能做什么事情,关注的是系统的外在表现.系统与人之间的交互.

《构建之法》阅读笔记04

今天,我阅读了构建之法10-12章.总结出了自己以前一些不对的思想和做法. 以前认为对软件需求最大的人肯定就是我们的典型用户了呀.于是就可以为这些人打造一款软件就等于软件成功了.可是大多数时候我们软件已做完发现这些人根本不用我们的软件.为什么呢?因为不会用.所以我们定义典型用户的时候首要条件就是会用这款软件,然后和需求有关系的用户. 以前认为工程师做软件就是先把要做的任务分分类,然后大家把自己的任务文成,最后链接起来就可以了,可是这样做出来的软件真的解决了需求了吗?软件设计是首先要把需求先搞清楚

软件需求模式阅读笔记04

今天开始阅读<软件需求模式>的第7.8章,其中第7章主要讲的是数据实体需求模式,主要是数据处理的一些需求模式,而第8章讲的是用户功能需求模式,主要是介绍了如何应对用户的一些需求. 第7章数据实体需求模式,系统的开发者常常是以轻视,随意的态度对待信息,没有规则定义什么时候数据可以被删除,对丢失数据很松懈--而本章就是通过引入一种方案把所有的实体分为几个固定种类,增加秩序性和一致性. 活实体需求模式,它用来定义一种实体,它的信息需要保存,并且具有预期寿命.但是不能将它应用于系统配置的实体:而应该使

大道至简阅读笔记04

本周我阅读了<大道至简>的第4张——流于形式的沟通,读后反思与感慨也是颇多的,下面与大家分享一下. 为不存在的角色留下沟通的渠道,这一节对自己来说体会是最多的.之前我们或其他自己所知道的团队中都存在这样一个问题:维护旧项目比做新项目更难:或是很多时候当项目负责人员离开后,项目就中断和中止. 许多人应该深有同感.     本书中对此情况进行了说明,把这一切的原因归咎于“没有history”.历史记录(History)与注释(Comment)不是一回事.代码中的注释是为阅读代码而留备的,而Hist

构建之法阅读笔记04

2017.4.1 今天我看的是绩效管理的内容,这是一个软件在阶段性总结时所不能逃避的话题,每个团队都应该有自己的团队绩效,应该用团队绩效来评估该团队的成员在这一阶段对这个软件做出的贡献.这好像的确是一个问题.我们应该从不同的方面来评估一个人在这一阶段对软件做出的贡献.单单从一个方面去评估一个人的价值是不合理的. 每个人在每个方面的贡献都是不可低估的.另外这章中还提到了团队合作的几个阶段,开始大家聚集在一起,是团队的萌芽阶段,每个人都很生疏,不知道做事的流程,不知道在团队中该怎么做.接着团队进入磨

《UML大战需求分析》阅读笔记04

在学习了前面的几种UML图并不能满足所有情况的建模,如当流程图涉及到多种角色,并且通过对多种角色交互展开时,顺序图才是不二选择.顺序图就如同中文语法的说话语言相似,描述的是一种事件发生的顺序.顺序图分为循环及分支语法结构两种语法.它强调的先后顺序. 作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙.业务用例在整个软件开发过程可以获取需求,在整个项目开发过程中起到指导

构建执法阅读笔记04

第九章 项目经理 项目经理的作用 协调团队成员的工作内容,把握产品定位和方向,解决用户痛点,调节团队中的矛盾,总控团队的进度,使一个团队加强交流.在一个团队中,项目经理是必不可少的一个重要角色.一个合格的项目经理需要良好的沟通能力,通过和团队成员的沟通交流,使一个团队能够有效地运转.同时,项目经理还需要及时的了解用户需求,精确地把握软件的定位与方向.而且还需要有长远的眼光和独特的见解,是产品的功能更加完善 第十章 典型用户和场景 在做一个产品之前,我们应该明确产品所需要服务的用户,为不同的用户建

编写有效用例_阅读笔记04

第十一章作为本书的第一部分的最后一个章节,提供了几种可供选择的用例格式.第一种是完整正式的用例格式,首先是单列文字,其次没有条件语句,最后便是扩展的部分的编号规则是数字和字母的组合.我个人在看了本书之后,比较喜欢这种格式,其原因一是从前看到后看习惯了,另一个原因就是扩展部分的编号规则更能让我接受. 在看了几个格式后,不禁好奇,怎么会有这么多种的模板来参照,如此不严谨的确不像是我们这类工程类的文档的要求,往后看才知道,原来影响用例书写格式的因素很多,从社会文化到理解层次到项目人员的相关要求到经验到