敏捷教练其实就是精益敏捷方法论、工程实践的专家，也可以理解为遵循敏捷原则的研发教练，他有魅力、能力、工具、方法去推动组织 团队的敏捷层面的转型。教练对敏捷教练来说，是重要的手段 方法而已。假如敏捷教练不具备专业教练领域的能力，他也可以通过他自己的方法和经验去推进敏捷的变革。但是，区别在于，如果他有专业教练这项软技能...【阅读全文】

在项目的开发中，应当让这类人员较早地进入项目。特别是在项目的启动阶段，让高级工程师或专家参与到项目的管理计划的制定，及早把握项目的技术业务方向的选择、开发流程、基准等，如果有可能在项目的后续阶段作为项目的核心骨干把握技术方案、项目基础以及主要业务需求。当然如果是公司级别的专家，从公司的运营角度如果不是特别重要的项目...【阅读全文】

如果你足够了解敏捷团队，你会知道敏捷评估的是 "团队的绩效(performance) "，从不评估个人绩效。这背后的逻辑是 - 评估团队，会促使团队成员思考如何合作的更好。而评估个人，会造成个体的竞争，导向内耗。说个最常见，而且看起来公平的 "团队之星 "评比规则：谁做的工作多，谁季度末就能拿最佳员工。没毛病吧？！ 就是在这个规则的...【阅读全文】

原因：你要是团队中的一员，PM也好， SME也好，恰巧又懂点Agile coach技巧，那么去coach其他团队吧。身在其中，观点就无法客观。另外人总是很容易看到别人的行为带来的影响(正面或负面)，对自己的行为造成的影响往往过于乐观。我还听说过一个coach在团队工期紧的时候，跟团队一起加班编码。那么团队从coach那里学到的，就是工期紧的时候，...【阅读全文】

大约两年前，我在与产品线一位负责人做工作沟通，当我们谈论如何在团队协作已取得阶段性成果后怎么再扩大成果时，这位老大主动跟我推荐了一本书——《团队协作的五大障碍》（Patrick Lencioni著），我被故事情节中主人翁如何化解危机，关键时刻的处事智慧所折服。后来工作上，一旦遇到涉及团队合作领域的，我都会多些停顿和思考，比如：同样...【阅读全文】

好的团队，从关键业务指标获取启发，通过观察用户的痛点、分析用户使用过程中产生的数据，不断尝试新技术解决现实问题。差的团队，从销售人员和用户那里收集需求。好的团队，理解谁是主要干系人，干系人所受的约束，承诺引入解决方案，方案对用户和客户有用，同时也满足业务上的约束条件。差的团队，从干系人那里收集需求。 好的团队，掌握大...【阅读全文】

原来方法并不重要，我们想做一件事情最重要的是“人”，其次是“机制和文化”，最后才是“方法和技术”。我的OKR+影响地图+看板+Scrum看来可以先放放啦。【阅读全文】

软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径，无止尽的输入，更何况比这个更复杂的商用软件。如果你们担心没有尝试过全部的路径不可靠，疑惑我们怎么敢说这个软件质量是好的还是坏，都有什么风险。请你们先注意，我们是跟业务分析师一样，...【阅读全文】