随着mobile设备越来越强大，在mobile设备上购物社交几乎已经取代了web端。
很多公司会单独成立app团队开发移动端产品来满足市场需求，Native（IOS, Android）， Hyberate, Mini Programe。
那么在APP团队里，user story应该怎样去组织呢？
先看app 产品的特点
前端有IOS ， Andriod两部分，
- 后端提供一份api给两个前端使用
- 前后端发布有时间差，后端发布比较实时，但是ios需要提交到app store一般时间较长， android需要在不同平台上发布。
例如，想要支持用户将商品分享到微信的功能，User Story应该怎样写呢？
按照web时代的写法，应该是先写个user story
User Story: As user, I want to share product with my friend
再加subtask
- Subtask 1: [IOS] build the UI in IOS
- Subtask 2: [Android]build the UI in android
- Subtask 3: [API]provide api sharing
- Subtask 4: [API]Refactor ….
只有所有的subtask任务完成，user story才算结束。
这样写存在的问题是，当三方开发进度不一致是，user story就永远不能done，在计算团队velocity的时候会存在问题。
开发不一致包括
- IOS和android开发进度不同步（比如IOS开发已经完成，但是android延误了）
- 前后端开发进度不一致。一般如果前后端contract定义好的话，后端API完全可以提前写好先发布
其实这样前后端开发不一致的情况在web也存在，但是因为平台不多所以问题不明显。
和友人讨论下来，比较可行的办法是，分三个user story针对IOS， Andriod， API
比如:
As IOS user, I want to share product with my friend
As Android user, I want to share product with my friend
As …..
有点写不下去，因为按照User Story的原则，story是要针对某种用户类型的，那么API的story的用户是什么呢？这让我想到了其实以前也碰到过类似的问题，有的团队开发的内容并不包含前端界面，只是给另外的团队提供需要的service，不能说这样的团队做的事情没有business valuse吧。
友人一句话点拨了我，他说，
微服务时代，前后端分离时代，user story的user外延可以扩大了，系统也可以是user
于是，我把最后的API user story补齐
As Frontend, I need API Sharing, so that I can share product with my friend.
我把业务描述放在了so that, 这样就能知道这个api是为了完成哪个具体的功能。
在拓展到别的场景
As xxx System, I need API getOrderInfo, so that I can show order detail to customer.
另外，可以用别的方法把这三个story关联起来，比如jira种的epic，link，label。
不再纠结。。。
网友评论