反馈一：

在两个Sprint之间有三个会，计划会、演示会、回顾会。

有人抱怨时间太长了，讨论太多了，真正用在产品上的时间倒被占用完了。

 

反馈二：

我们的燃尽图前面一点都不会变化，甚至我已经预料到燃尽图会是阶梯状的，因为我们要花很多时间来稳定框架，这个不可测，如果非要为这个设计测试桩，那工作量就太大了，敏捷不起来，或者没法敏捷。（过几天会说，我当初已经预计到了。甚至这个阶梯只有一个台阶）。

 

“专注于技术”？

嗯，这是老问题了，工程师都是好工程师，都希望节约不必要的开支，“专注于技术”的技术人员是优秀的工程师，“专注于技术”几乎算是一种“美德”，我猜很多管理者也许比较喜欢这样的工程师。

 

但，“专注于技术”如果变成这样的情况，显然是一个危险的境地。

          听项目经理的话，做产品经理的活，一心一意做开发，两耳不闻用户声。

难道真的存在不考虑应用的技术？

那不成了“屠龙”之技

 

我举例描述了这个问题的意思：

一种是来自于环境比较，比如你和别人比觉得有些弱项使你处于竞争的不利因素，那就是压力

 

有个工程师告诉我，他的压力是：我想要做一个完美的产品，但事实上项目不允许我这样做，没有做出一个好产品的成就感，我的压力是我觉得这种情况不会得到改善。

 

之所以把这个调查拉出来说，只是为了说明前面关于“专注于技术”，应该是一个教育乖孩子的手段吧，事实上，很多工程师只是不愿意陷入看起来很无聊的会议中、才拿技术来做挡箭牌的。或者说，工程师对产品的想法没有一个好的出口，也是导致工程师只能选择“只管实现，不问需求”。