|
除了上述，我在公司里也和同事们经常利用业余时间开发一些「提效」的工具，我写的书《敏捷测试高效实践 测试架构师成长记》里面就介绍了一款：能自动生成接口自动化测试脚本的工具。
再多说一句，前段时间某位大厂的开发领导跟我讨论技术时，聊到了自动化测试这块，这位技术团队的大神认为自动化测试是割韭菜的概念，统统要砍掉。(我是真心服了)项目管理者联盟
那位大神在上线前，对着测试工程师说：「是时候展现测试工匠精神的时候了，我们从0造轮子，大家赶快用鼠标“点点点”，把所有功能都回归一遍」。我觉得这位所谓的「技术大神」内心是对技术是没有敬畏的，此时心疼他团队的测试工程师三秒钟。项目管理者联盟
7、试图用敏捷解决技术问题项目经理博客
敏捷只是个抽象的工具、不是解决技术问题的手段。很多公司老板会说：「你们不是敏捷了嘛，怎么这个xxx问题都搞不定?」项目管理者联盟
开发过程中遇到的各种技术问题，最终还是得靠技术能力去解决。项目管理者联盟
大家可以参考场景三，这里不过多赘述了。项目管理者联盟
所以，想要搞垮团队呢，大家遇到问题千万不要着急，要冷静，因为今天解决不了的问题，明天也解决不了。项目经理圈子
8、不重视「人」，重「流程」项目管理者联盟
很多国内大公司都有这个通病，为了不让某位人才成为公司进步和发展的瓶颈，通常会把他的工作进行拆分、分解，由流程代替人才的稀缺性。项目管理者联盟
而敏捷团队恰恰相反，敏捷团队的规模很小，敏捷的基础就是团队，敏捷是由人来参与的，重视团队中「人」比重视敏捷中的「流程」更有意义。项目管理者联盟
如果你是某个团队的负责人，可以自己问自己2个方面的问题：pmp.mypm.net
1）、有没有真正的尊重团队中的每一位成员，有没有充分让他们发挥自己的才能?有没有帮助他们成长、给予更多进步的机会?项目管理者联盟
2）、团队中的创新情况如何，可以落地吗?有没有造轮子?能不能真正解决团队中的痛点?转自项目管理者联盟
作为团队的负责人，如果没有在团队身上花时间，能导致的结果只有：团队的核心人员不断流失，团队的普通成员没有工作想法，你说干什么他们就干什么。项目管理者联盟
最终，使团队中的所有人统统躺平：岁月静好，现实安稳，KPI和OKR(还有Google刚刚宣布的GRAD)随缘吧，一切都是最好的安排。项目管理者联盟
从敏捷中的价值观就可以看出来，敏捷开发模式是很在于「人」这个主体的，毕竟所有的敏捷活动都是由「人」来参与完成的，提高人才密度才是实现团队敏捷的正确姿势。club.mypm.net
9、没有请真正的敏捷教练项目管理者联盟
什么?还需要敏捷教练?请一位敏捷教练的费用这么贵，我们自己学习学习，直接自己当教练就好了嘛。既省钱，还能学到东西， 一举两得。talent.mypm.net
况且我的友商早就敏捷了，我们连抄作业都不会抄吗?你还别说，我们程序猿都是绝顶聪明的人，我也不例外，虽然我只是绝顶而已。项目管理者联盟
找一名真正的敏捷教练，能带给团队一种精神上、思想上的洗礼，这是和自学成材的敏捷教练最大的区别。项目经理博客
很多要点、坑、优秀的实践、业内最近流行的工具等，这些知识都能从他们那里获取，这是自学成才的敏捷教练所不具备的。项目管理者联盟
10、既然敏捷了，还要什么文档项目管理者联盟
敏捷价值观里提倡的是：可以工作的软件要高于详尽的文档。并没有说就不要文档啊!项目管理者联盟
不重视文档这件事，在项目前期还好，产品的业务逻辑大家脑子都记得很清楚。但随着时间推移，随着团队成员的离职、入职、借调和请假，随着讨论的更加深入……。www.mypm.net
|
