編者按：最近技術故事如何處理的話題，頻繁提起，整理這篇對話，來說明下。 這個對話的結果見 另外一篇博文- 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
賦能感覺比使能更常用些
技術投資類故事，贊的
核心意思是一致的

總結

以上是生活随笔為你收集整理的关于开发工具环境准备事项作为故事来处理的对话的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。