关于开发工具环境准备事项作为故事来处理的对话

编者按:最近技术故事如何处理的话题,频繁提起,整理这篇对话,来说明下。 这个对话的结果见 另外一篇博文- http://blog.csdn.net/zhangmike/article/details/52266848 “用户故事的扩展-新的故事类别”

张克强:大家空不,探讨一个具体的词汇问题:
为了开发工具、环境等等做准备的一些事情能不能归为user story?
一般不能,如果不能的话,给个什么样的说法?
开发者故事如何?
如果有了开发者故事,要不要加测试者故事?

Ligp 13:55
建议不是。可以归于穿刺,或其他task。总之不建议为用户故事

乐乐 13:56
这些事务我们都写成一个纯任务去完成,不写story

张克强 13:56
safe给出了 enabler story的提法。
使用电子工具来管理这些的情况下,希望对等的处理故事。统一用相同的维度来进入到迭代待办事项。

张克强 13:58
所以优先用 故事
因为task在另外一个层面

露西 13:58
team velocity不包括解决这些环境问题。DevOps engineer做的工作是on demand的,不好计算velocity。

张克强 14:10
我公司使用非功能类故事这个说法来处理,与功能类故事一起,现在发现非功能类故事这说法怪怪的

enabler story在英文世界是个很好的提法。但中文很难翻译好。
enabler story译为推动者故事,如何?

圣略PMP ACP-布丁 16:23
在硬件编程里面,我们叫enable使能,我觉得也可以叫使能故事

露西 17:10
要正确理解为什么需要每个人的工作可视化,是为了每个人都为高优先级的,业务价值高的故事努力。并且每个iteration团队都为了一个目标努力,要focus,要有outcome。
这样的话,你就可以处理每个人应该做哪些story
PO在iteration planning时把优先级定好了。在iteration里面,用MoSCoW选择,团队commit的东西必须要deliver,其他东西可能被urgency或者change替代。

张克强 17:50
NFR一般是指包括性能在内的非功能性需求,灾备,压力等等,但它仍然是表现在产品或者系统上的。
与开发环境工具方法改善有差别的

张克强 17:52
非功能性故事之所以怪怪的, 就是因为与非功能性需求混淆

春山 18:08
enabler story: 赋能类故事;
与NFR不是一回事。

张克强 18:25
@春山 谢谢
又得到一个好说法
赋能类故事这个说法在中兴,已经流传了吗?

苏春山-中兴 18:47
no,我们叫“技术投资类故事”,“赋能类故事”是刚在我脑子中闪过的。[呲牙]

张克强 18:52
赋能感觉比使能更常用些
技术投资类故事,赞的
核心意思是一致的

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页