敏捷开发中的角色 用户故事 角色一定是人吗

来源：蜘蛛抓取(WebSpider) 时间：2017-07-15 08:13 标签： 敏捷开发 ba角色
敏捷开发必须要通过用户故事来沟通吗？ - 知乎36被浏览2921分享邀请回答6添加评论分享收藏感谢收起与世界分享知识、经验和见解敏捷开发目前已成为互联网公司的首选方案，为应对市场的快速变化，我们公司也在大力推广敏捷，最近在读《用户故事与敏捷方法》一书，我想边读边做一些分享，传播知识的同时加强记忆。
基于用户建模是一个比较好的起点。
敏捷开发目前已成为互联网公司的首选方案，为应对市场的快速变化，我们公司也在大力推广敏捷，最近在读《用户故事与敏捷方法》一书，我想边读边做一些分享，传播知识的同时加强记忆。
基于用户建模是一个比较好的起点。
产品团队可以采用头脑风暴等形式，挖掘出产品实际存在或者潜在的用户或客户，给他们一些角色。
多种角色出现重叠时，再将重叠部分成立一个独立角色。
比如“运维角色”和“部署角色”都需要做一件事情：做数据修改，那么我们就考虑一个“数据修改角色”专门做这个事情，然后“运维角色”和“部署角色”就都不包含这个职能了。
再然后呢，给每个角色找一个生动的虚拟人物来代替，让团队熟悉这个人，就像身边的一个朋友一样了解。
例子：“借款人角色”，代表人物叫“张穷”，30岁，小餐馆经营者，这两年生意做得不错，想扩大店面，但是手头吃紧，正绞尽脑汁想找一笔贷款。
用户建模时，可以考虑一些特殊的人群，他们有助于发现一些细致的需求。比如老太太需要屏幕字体够大。
寻找用户。
最理想的方式是能够找到软件真实的使用者，了解他们的需求。
条件不成熟的情况下就只有寻找用户代理，不同的人群都可以担任用户代理，但是要注意不同的用户代理看待问题大多是从个人需要出发的，要摸清他们的一些小脾气。
实际用户的经理：他们对于产品细节的关注度可能不高，因为他很可能平时不做实际操作，对于群众疾苦了解得不够；他们可能会过分关注一些管理功能，比如任务调度、查看每个手下现在的任务完成情况等，而这些功能很可能不是产品核心的东西。
开发经理：他们通常缺少对软件的实际体验，其内心驱动因素很可能是业务压力或者成就感，这样的动机很容易背离产品核心业务价值。
销售人员：他们的核心价值观通常是尽量多的订单，为了不丢单，他们总会承诺“没问题”，各种稀奇古怪的东西都想丢进产品里面，使得产品没有规划、随遇而安。
领域专家：他们通常能够在产品设计上提供很大的帮助，但要小心他们弄出一个太“高大上”的东西，不接地气，让小白的用户觉得软件极其难用。
系统分析师：他们是很有想法的文艺青年，既懂技术又懂业务，是很好的用户代理。但要小心他们的空想症，他们有可能花上两天去精心设计一个业务流程，但根本没有做过任何调研。最坏的结果是最后不得不推翻一个精心雕琢的楼阁，浪费、肉疼。。
切割故事。
传统的切割方式大多是按实现层面或者技术栈来切割，比如一个功能别切割为前台、后台、数据库几个任务，或者按照技术栈切割为java相关、C#相关、移动端几个任务。
这样的切割方式最大的问题是：单个任务不能产生业务价值、相互依赖导致无法快速交付并得到反馈。
推荐做纵向的切割，每个故事尽量是一个功能闭包，一个故事完成意味着一个功能可交付。
以京东提交订单功能为例，其业务流程为：基于预先选好的商品信息，先选择支付方式、再选择配送方式，然后提交保存。
传统的切割方式可能为：
T1: 前台交互实现（选择支付方式、配送方式），形成可提交的订单数据后提交给servlet
T2:后台接收订单数据，保存到数据库，给成功提示。
考虑换一种切割方式：
S1：基于预先选好的商品信息，使用默认支付方式和配送方式，提交订单并保存。
S2：支持用户选择支付方式并保存订单。
S3：支持用户选择配送方式并保存订单。
我们不要写哪种大而全的故事，一个故事只为一种客户编写，只满足其一个小小的业务价值。
编写故事时尽量避免涉及界面的描述，这会诱导开发人员按照某人脑海中印象来实现功能，这实际是把设计意图强加到故事之中，更致命的是会隐含的扩大故事范围。
比如这样一个故事：
在首页的右上方，用户可以看到“注册”按钮并点击它，之后弹出一个对话框，用户录入注册信息后，点击提交按钮，若注册成功就回到首页，并发送激活邮件。
它的问题：
涉及太多的界面信息，它阻止了开发人员或者分析师跟客户做进一步沟通的欲望，也许这样的交互设计是蹩脚的呢？
考虑写成这样也许更好：
在首页醒目位置可以进行用户注册，注册成功需要发送激活邮件，注册失败需要失败提醒。
用云栖社区APP，舒服~
【云栖快讯】首届阿里巴巴中间件技术峰会，揭秘阿里10年分布式技术沉淀！阿里高可用体系核心缔造者、全链路压测创始人，DRDS与TDDL负责人等大咖出场，干货分享，不可错过！&&
大数据开发套件（Data IDE），提供可视化开发界面、离线任务调度运维、快速数据集成、多人协同工作等功能，为您...
帮助您基于阿里云构建出一个隔离的网络环境。您可以完全掌控自己的虚拟网络，如选择自有 IP 地址范围、划分网段、配...
提供了高性能可伸缩的容器应用管理服务，支持在一组云服务器上通过Docker容器来进行应用生命周期管理。
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
2017杭州云栖大会火热抢票
Loading...敏捷开发必须要通过用户故事来沟通吗？ - 知乎36被浏览2921分享邀请回答1添加评论分享收藏感谢收起与世界分享知识、经验和见解知乎用户敏捷开发用户故事系列之一：何为用户故事 - 阳光VIP - 博客园
少壮不努力，老大徒伤悲。平日弗用功，自到临期悔。
posts - 1395, comments - 6, trackbacks - 0, articles - 0
这是敏捷开发用户故事系列的第一篇。（，，，，，，，，）全系列将涉及何为用户故事，面向客户价值编写故事，用户建模，产品待开发项的分类，故事颗粒度，故事的组织结构，等等若干问题，力求将此中问题尽量解决干净。本系列文章假设正在编写一个“敏捷开发管理软件”，因为来阅读的都是做敏捷开发的，又都是做软件的，会更熟悉一些。用户故事三要素：角色，功能，价值按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就是用户故事。样式是技法层面的东西，它保证了无需太多思考，用户故事中即包含角色、功能、价值这三个要素。角色角色切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解他们使用什么功能，如何使用，为何使用。比如“作为一个开发人员，可以登录批量编辑页面，以便高效率地编辑多个故事”就是一个危险的举动，因为如果有多个程序员同时这么做，存储的时候会发生冲突（这个页面后来被删除了）。但“作为一个项目经理，可以登录迭代计划首页，同时编辑多个迭代的信息”则是可行的，因为项目经理一般就有一个，而且这个功能使用次数很少，即使有多个人有权限使用，偶然发生冲突的损害，与平时效率提高相比，也微乎其微。所以把角色特化出来后，更容易理解功能的价值和风险。日后另有文章详述如何识别角色，以及如何基于关键角色编写故事。功能功能即用户能亲自执行的操作。应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。一个例子是之前我使用一个XX手机，联系方式上在“拨出”之外，总是有一个“编辑拨出”，后来才知道是为了能在前面加拨17951之类的IP电话前缀。写成用户故事，差不多是：“作为一个用户，可以使用编辑拨出在拨打长途前输入IP前缀，以便节省话费。”不过这个功能从来没用过，因为太费劲。实际使用中要么我会把外地电话录入的时候就加上17951，要么一个电话就打出去了管它三七二十一。后来又使用另外一款Android手机，因为别的原因安装了360，发现它有一个自动IP功能，写成用户故事，就是“作为一个用户，可以在拨打长途的时候自动使用IP拨出功能，以便节省话费。”这个功能每月可以给我节省不下20块钱，如果他有一天收费，我必会买。价值价值是完成操作后，客户所得到的价值。价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如前面的“高效地”“节省话费”。潘家宇老师当年提到何为“用例”的时候提到了类似的概念：“用例就是那个你能卖掉的东西。”用户故事也是用来被卖掉的东西，看不到价值的就不是用户故事。比如上面的360的用户故事写得就比较好，估计如果有读者没装360，看完本文立刻就去。底层的一些功能看不到直接的用户价值，怎么办？系列中另有一篇描述用户故事的分类。&本篇先简单说明一下用户故事的定义，更多内容将逐步展开。&点击下载免费的敏捷开发教材：《》&

我要回帖

更多关于 敏捷开发 ba角色 的文章

 

随机推荐