吐槽领导的事情可以，吐槽人，那就不那啥了。为什么人家能坐领导，你不能。是值得思考的问题。要换位思考，站在角色岗位上想问题。

要问责大目标。比如发布后的有严重问题，产品，开发，测试共同担责。让团队自己去找原因。

产品经理和开发团队的矛盾无法避免，归根结底产品经理和团队的利益并不一致。这要求一个有效的问责制度。

#6 楼 @anonymous 你难道是我司的~~？

要做有专业技能的万金油。

to be agile, no do agile. 敏捷，团队是第一关键，国内真正达到标准配备的不多吧。说白了，不就是要高效吗？如果团队够牛，目标一致，干劲十足，精神饱满。想不敏捷都难。

那就让产品出问题。并且责任不完全在测试的问题。出了问题，也许就能改观。

下期，小道消息有话题了，吼吼！

诶 说明确，项目开始前都说的好好的，到时候给的东西就不是那样的，自己不按时间完成，最后还压测试的时间。文档不是最新的，去问研发，研发说这个产品跟他们商量定下来改的，可文档不是啊，工期太紧了，测都测不完，总不能不干吧，非让他补全文档我们再测也不是那么回事，现在的老板特别看重这个产品经理，夸的跟花是的，实际上没什么能耐，就会哄老板，说的比唱的好。郁闷

喷他

提测是开发的事情啊。产品文档不过关，没有评审？那你们测试根据什么测？你要做足功课，找他们的毛病，让他们完善。邮寄反馈，把老板加进去，数据说话。

#9 楼 @anonymous 你能有这样的体会，说明你们做的有起色了。

这点我这弄的相当成熟了。产品提交测试前要验收是否都按需求来做的。测试阶段发现文档和产品有出入，直接拒绝接收测试，一旦打回重新验收，发布日期势必会延后，但，这不是测试的问题。追责也很容易定位。

遇到这种人, 就得划分好界限了. 明确下交付物, 每次走提测流程, 最后根据测试时间和提测次数, 跟他们一起算账吧. 测试时间和资源安排要摆到明面上和他谈.
不然他就会认为你们都是打杂的了

辞职

#12 楼 @anonymous 你看出来了！！！

#3 楼 @anonymous 一看就是思寒

我对公司敏捷的最大的感觉就是 站例会，写白板，看板。更像是一种有效快速的梳理问题，并跟进解决。

好快

#6 楼 @anonymous 你觉得你可以概述下不赞同的理由

哈哈，这个话题好，为此还写了一个” 敏捷黑 “的主题，有十几篇文章，不敢都发了，怕砸了自己的饭碗。，也可能只是我在抱怨和吐槽而已。不过很幸运地碰到一些做专业商业软件的 QA，一个软件都价值百万以上，和我有同样的看法。还是让敏捷回归它本来的出发点吧，这玩意也就互联网公司的免费小项目可以这么去折腾，其它的别在害人了。

看着很高端

说到底敏捷到底是个什么东西没人能说得清，于是画虎皮扯大旗的人就多了。

国内能做到敏捷要求的公司太少，大部分都是在做伪敏捷。而且真正干活儿的人都被敏捷弄得焦头烂额的。。。领导们却都乐此不疲。其实能把控好短迭代流程已经算是不错的了。

！！！！要成为万金油 也不是件容易的事