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

编者按：最近技术故事如何处理的话题，频繁提起，整理这篇对话，来说明下。 这个对话的结果见 另外一篇博文- 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
赋能感觉比使能更常用些
技术投资类故事，赞的
核心意思是一致的