【在线研讨-现场文字】《敏捷开发用户故事分类与组织结构（二期-4）》2012-07-03

一期：活动描述，之一，之二，之三，之四，之五

二期：活动描述，之一，之二，之三，之四，之五，之六

关于如何描述“纯技术问题”现场讨论

阚野-pm-北京(36916487) 13:38:12
勇哥 可以问问题吗

陈勇-创业-北京(139107533) 13:38:20
好，请

阚野-pm-北京(36916487) 13:38:27
对于代码结构重构 这个价值如何描述 是否可以说 使得代码结构更合理 更适合扩展新功能
或者 增加新功能时 出错率更低？
感觉这个很难量化描述

陈勇-创业-北京(139107533) 13:39:19
重构我们现在用的是：实现前，……（业务上的困难）；实现后，……（业务上的改进）。
不过，有些重构的确很难直接描述出用户价值
但可以在这里找到突破点：
1. 响应变化可以更快
2. 可复用的库，缺陷率会更低
3. 新的数据结构，能支撑更大的用户量……
等等，总之，所有技术人员在发动重构前，应该与PO讨论重构的必要性，而必要性取决于用户价值，而不是“技术先进性”。
QQ技术是很落后的，但如果有人力，不如投到微信上面，而不是把QQ用Java重新写一遍，取得“技术上的先进性”
答案大致如此。
是否可以回答一些？

Roy-Consultant-SH<[e-mail]> 13:41:50
这个用户应该还包含自身吧，自己也是自己产品的用户哦。在写用户价值的时候应该也把对自己带来的价值也写进去吧！
说实话很难确定，我们的重构写法也不很稳定。

陈勇-创业-北京(139107533) 13:42:51
是的 这些重构的目的是让程序员工作更顺畅

阚野-pm-北京(36916487) 13:42:38
但是很难对产品经理量化重要性

陈勇-创业-北京(139107533) 13:42:51
有时候我们会觉得重构只是让我们工作更快而已，但从客户角度看，就是对用户的变化和新功能响应更快，也是个用户价值。

阚野-pm-北京(36916487) 13:43:05
对

听说-码农-SH<[e-mail]> 13:43:08
有一个问题 重构中 或者说走某个方案中， 描述用户价值还算容易， 可是如何较为精确的量化呢？

陈勇-创业-北京(139107533) 13:43:29
比如我们上次重构一个ViewModel，可以更快，还能降低空指针的概率，这就是“更快响应用户并提供更高质量”

阚野-pm-北京(36916487) 13:43:43
但是难以对产品经理量化效果 比如 对用户需求响应由多慢到多快

陈勇-创业-北京(139107533) 13:43:53
如果需要，应该是可以量化的。
但要适可而止

听说-码农-SH<[e-mail]> 13:44:01
例如说 我们觉得会快 或者会提高生产力，或者降低bug率 但是提高多少呢？ 在开始

听说-码农-SH<[e-mail]> 13:44:56
我的意思是 有没有一种较为通用的方式 或者案例 可以较好的描述这些的程度呢。。

陈勇-创业-北京(139107533) 13:45:12
@马农：没有见过，呵呵。

陈勇-创业-北京(139107533) 13:45:02
比如如果说：重构要花费2天，但以后会加快很多。这就足以发起一次重构了，毕竟去证明到底加快多少，很困难也很无聊，应该相信技术人员的判断了。

听说-码农-SH<[e-mail]> 13:45:30
我们作为技术人员可以感觉的出来这个速度 当然 只是感觉 也不是量化

陈勇-创业-北京(139107533) 13:45:36
不过如果是：重构要花费200天，但日后就……了。则需要仔细想想了。

听说-码农-SH<[e-mail]> 13:45:54
但是客户或者经理 有的时候不接受这种解释额。。。。 他们能看到投资 但是benefit不够清晰

陈勇-创业-北京(139107533) 13:46:00
总之，先发动大家从“用户是否需要”这个角度思考，再说纯技术，或对未来开发的好处。
@马农：恩。不过，如果这不是第一次，而是一个经常协助思考用户价值的团队的偶然一个说不太清楚的故事，PO多半会同意。
可怕的是如果一直没说清楚，而且团队显然从来不思考用户价值，才真是一个可怕问题了。
好，时间有限，继续了。