当遭遇系统的切面功能时，如何去写user stories呢?

这段时间在看如何实施敏捷开发方法，仔细看了如何写user story ,还有很多疑惑的地方希望得到各位的指导。
当写user stories时，如果一些功能是在用户描述每个功能时都会涉及到的，我暂且称为切面功能吧，
比如一个系统中的用户访问行为记录，权限设置功能等。
此时我们如何处理这些切面功能呢，是按用户的描述，把切面功能分别放入各个user stories中，
还是单独拿出来作为一个user stories来实现呢？
当然如果权限简单的话，可以融合到具体的各个user stories中，
如 http://www.iteye.com/topic/53246
这里讨论的，角色和权限比较简单，就可以把功能划分，并分别放入相应的user stories即可。
但是一个复杂的权限系统，需要对系统进行整体考虑，然后单独进行设计来实现，
这样的话，把这些切面功能放到各个user stories中显然是不合适的。
例如一个权限的例子：如果用户查看数据时，需要达到这样的控制，用户属于具体的一个省份，因此默认情况下用户只能查看所在省份的数据，但管理员可以看到所有省份的数据，同时管理员可以指定某些用户一些省份列表，使他们能查看多个省份的数据。
这种权限该如何写到user story中去呢？
还希望那些实践过user stories的兄弟们能够指导指导

评论

11 楼 抛出异常的爱 2008-09-01  

我正在维护的一个系统
不知道什么意思
里面就是有几个不用实现方法的接口。

在查找时用IDE很快能找到这几个实现类，很是方便。
比在spring里瞪眼找可方便多了。

10 楼 nonocast 2008-09-01  

抛出异常的爱 写道

对于一个接口进行描述。。。。
之后重构时把需要的类加上这个接口。。。
就像写一个普通功能user story一样。


PS：这个接口不需要有必须实现的方法。

这样的话还是需要考虑设计问题，如果都这样考虑的话，上来就会存在本身用不到的接口集，虽然是空的，但依然要花时间去验证，因为很多接口都是在重构中不断调整，放着的意义并不大啊

9 楼 抛出异常的爱 2008-09-01  

对于一个接口进行描述。。。。
之后重构时把需要的类加上这个接口。。。
就像写一个普通功能user story一样。


PS：这个接口不需要有必须实现的方法。

8 楼 fly_ever 2008-09-01  

evanyuan 写道

User Story细节不清楚，Use Case的话，看看以下两方面是否可行

（1）划分业务需求和系统需求，记日值这种可列为系统需求，针对该需求添加单独的UseCase，在需要使用到该系统需求的业务需求中，添加注释，比如“该用例遵守XXX系统需求”

不知道user story是否可以按这样分为描述业务的story和描述系统的story？如果可以这样分的话，那倒是可以把切面功能作为系统story来实现，等系统story实现之后，再按相关的约定来实现业务story。
以前只看到用户故事可以描述非功能需求，如http://www.iteye.com/topic/16904中所写。

7 楼 fly_ever 2008-09-01  

nonocast 写道

在敏捷估计与规划中写到:
12.4 去除横切考虑
....
指导原则:考虑出去横切考虑(例如安全处理，日志记录，错误处理等),为用户故事建立两个版本:一个具备对横切考虑的支持，另一个不具备这种支持。

版本1，不考虑横切功能的user stories:
普通用户，能查看所在省份的数据
管理员，能查看所有省份的数据
版本2，考虑横切功能的user stories:
普通用户，能查看所在省份的数据，以及能查看管理员授权的省份的数据。
管理员，能查看所有省份数据，能为普通用户授权。
这时候，第一次迭代实现版本1的user stories，第二次迭代实现版本2的user stories。
也就是说，在敏捷估计与规划这本书中的观点为，把切面功能分别放入各个涉及到的user stories中，分多次迭代来达到实现切面功能的目的。
可我还是那么觉得

引用

但是一个复杂的权限系统，需要对系统进行整体考虑，然后单独进行设计来实现，
这样的话，把这些切面功能放到各个user stories中显然是不合适的。

6 楼 evanyuan 2008-08-31  

User Story细节不清楚，Use Case的话，看看以下两方面是否可行

（1）划分业务需求和系统需求，记日值这种可列为系统需求，针对该需求添加单独的UseCase，在需要使用到该系统需求的业务需求中，添加注释，比如“该用例遵守XXX系统需求”

（2）象权限这种，在需求文档中，未必非要写到UseCase中，你可以列个单独的章节，对系统进行角色权限及通用规则的描述。如果只是很少的业务需求涉及到权限，或者说差异太大很难总结出通用的规则，那么可以在UseCase里加个Memo项，作为对操作步骤的补充说明。（每个UseCase的Actor本身是否可以说明这个操作的使用者身份？）

5 楼 nonocast 2008-08-29  

在敏捷估计与规划中写到:
12.4 去除横切考虑
....
指导原则:考虑出去横切考虑(例如安全处理，日志记录，错误处理等),为用户故事建立两个版本:一个具备对横切考虑的支持，另一个不具备这种支持。

4 楼 fly_ever 2008-08-25  

我想这个应该是涉及到敏捷开发中的隐喻(metaphor)的问题了。
在从最简单的权限系统做到复杂的权限系统时，把user stories分得更细，在几个迭代的周期中来实现，并不断的进行系统设计和重构。

引用

如果你知道怎么做，你就要考虑现在做和将来做，这两种情形之间不同的成本。反过来说，如果你没有处理过那样的问题，不仅是你无法正确判断需要的成本，你也比较不可能把事情做好，这种情形，你就要选择将来再做。

3 楼 nonocast 2008-08-23  

不知道是否可以这样理解
一个用户层面的功能点或者说是UserStory,都是由横向和纵向构成的。
横向就是你说的切面，用户权限，数据库，网络库或者日志等，纵向就是具体任务，查看省份数据。

相当于这个UserStory由2部分组成，他的进度也由这2部分承担，
你可以先完成切面工作，也可以先完成具体任务而忽略切面，2种都可以，视具体情况(进度)而定。

2 楼 fly_ever 2008-08-22  

tobato 写道

为了保证系统的安全,作为使用系统的的普通用户,默认只能察看所在省份的数据.

为了保证系统的安全,作为使用系统的的管理员,可以察看所有省份的数据.

为了保证系统的安全,作为想要查看其它省份数据的普通用户,必须通过管理员的授权.

如果写user story的话，这样是不是更好点：

普通用户，能查看所在省份的数据，以及查看管理员授权的省份的数据。
管理员，能查看所以省份数据，能为普通用户授权。

我的意思是，如果按这种方法来写的话(不管是你的写法还是我的写法)，那权限这些功能就需要分别在各个user stories中去实现了。
而权限这个功能是需要统一考虑的，可能统一在后台实现了权限相关的功能，我们才好去方便的实现上面那些user stories。
那这样是不是说我们就需要根据权限的需求，来写一个user story，也就是把上述的user stories中有关权限的功能单独拿出来，用来描述权限呢？
比如：管理员，能为普通用户授权。

可这样的话，又出现了问题：
敏捷开发中，写完user stories后，确定优先级，然后可以任意选择某些user stories来实现，这样说来，user story的实现是没有严格的顺序的。
可如果我们加入了权限相关的user story之后，则需要先实现这个权限相关的user story，然后才能去实现其他的user stories。

敏捷新手，还希望能够得到各位的指正

1 楼 tobato 2008-08-21  

为了保证系统的安全,作为使用系统的的普通用户,默认只能察看所在省份的数据.

为了保证系统的安全,作为使用系统的的管理员,可以察看所有省份的数据.

为了保证系统的安全,作为想要查看其它省份数据的普通用户,必须通过管理员的授权.