【敏捷江湖桃花岛】华山论剑第一期 (下）

【敏捷江湖桃花岛】华山论剑第一期 (下）

问答四：

Q（主持人）：刚才有网友发弹幕想请教悟空大师，产品负责人没有时间参加sprint，要求重新安排会议，那么scrum master应该要求怎么做？

A（悟空）：这道题确实很难，首先如果事情已经发生了，那么能做的事情就已经很少了。就很多时候我回答问题，如果你没带上具体的条件，我会告诉你具体境况下怎么去解决。但是，当你说就到了目前这个时间点，明天早上就要开计划会议，然后今天产品负责人给你打电话说，我明天参加不了，请问你怎么解决？没办法解决。所以，这种情况肯定是不可能解决的，因为很多功夫要做在前面，就像我们说的，会议要做好准备工作，准备工作必须做在前面。

但我们回过头来看，就是这个事情怎么解决？第一，这取决于这个产品人是一个怎样的产品负责人，如果他是产品负责人，那意味着他不是客户，因为产品负责人原本来讲是客户的代表，那你也可以问他，我可不可以请客户来参加，让客户直接看。另外一面，如果产品负责人是偏内部的，那么可不可以我们内部先代替，如果你有时间的话，我再跟你对，对完之后，将剩下的东西排到下一个sprint，从流程上来求解；另外，也可以看你跟你们的PO平时的交流好不好。你的story有没有在一开始就将验收标准讲清楚，因为我们的实践是不会出现这些问题的。

很多人会觉得这是相对于的理想化，但对于我们来说，这是相对的，做到的一个情况。第一，在一开始你的sprint有没有讲清楚，因为我们的迭代周期是固定的，也就是说，我们从1月1日开始，我们整年的sprint都已经排完了，因为我的sprint固定，会议时间固定，所以我一年的会议时间都已经排完了，所以对我们来讲是不大可能存在这样的问题的，从一开始我就已经跟你把时间约定好了。PO一定不是市场那面的，人员的选择，PO一定不是一个偏业务的人，他一定是一个研发的人，因为他要支持团队，所以在我们的PO是会经常跟我们交流的，因为我们要确保产品梳理是对的，所以会议上的需求都是清楚的。需求清楚是指，需求要讲清楚，然后格视要有，要有验收标准。

对于我来讲，因为我一开始是做测试的，我跟吕艺涵争论过，到底这个验收标准到底是什么？我怕认为它实际上就是一个测试策略，也就是我要测试一个场景，对于需求来讲，还有他的子场景我都要测试，这些子场景每一个都可以导出好几个测试用例，所以很多人这个实例化测试，AC用例叫测试用例，我说这是不对的，你这是不懂测试。我们的测试用例全部自动化的，开发从一开始就写伪代码，他写伪代码，我写测试代码，一般第一天第二天，我的测试就是可以运行的，我的包是可以运行的，只是他的返回一个1，我的仍然可以运行，所以不存在PO不来参加，他来不来参加都无所谓。

所以，如果在这一刻他必须参加，你又说服不了他参加，那就没有办法了，要么延期，要么在会议开完后，选择二次对其，然后再把二次对其的差距，在跟团队来沟通。我觉得在这一刻你只有这种选择，但是如果在未来的话，你就要跟PO去搞一下关系，跟他做一下思想工作，让他认同这个理念，尊重这个团队，大家是一家人，你说不来就不来，你当我们是嫁人了吗？

我讲另外一个点，首先，scrum master我曾经形容他为政委，也曾讲过他是太监，你要给大家做思想工作，你是粘合剂，你不可能给大家讲敏捷是最好的方法，让所有人这样做，侯君君7这是不可能的，如果这样子的话，灭霸早就天下第一了，所以你一定要跟大家做思想工作，让大家认可你，理解你，这是scrum master要去做的。

有人问AC和测试用例的区别，我这里举个例子。我原来辅导过工商银行，举电商的例子，两百块以下，运费10块，两百块以上，免运费，京东plus会员，淘宝88＋VIP会员，始终免运费，这就叫AC，不同的运费政策，不同的资格，不同的运费处理情况。但是你小于两百元，你得撤几个，1块钱你得测吧？199你得测吧？200块你得测吧？这叫测试用例，这就是AC和测试用例的区别，所以AC更像是一个场景，或者更像是一个规则。原来我给工行解释说，这是一个业务规则，但业务规则在不同的情况下肯定是有很多的。另外一点，咱们测试圈中，敏捷出身的人还是比较少的，希望我们能多出几个测试背景的大师。

问答五：

Q（丹阳子）：我想问一下，对于一个想转型敏捷的团队来说，人是非常重要的，如果想系统地学习敏捷，参加什么样地敏捷体系？因为由于这个体系比较好，这类的培训比较多。

A(悟空）：第一，我觉得，如果从学习的角度来考虑，其实都可以，博采众长，但是我也在一些演讲中也讲过，我建议你选一门，先学到深，然后在考虑突破。如果你一开始都不理解这个东西，你就觉得这里可以调整一下，那里可以调整一下，最后的结果就是四不像，所以我们以前在论坛上跟很多人吵架，很多人就说，你这个scrum怎么这么不灵活,这个也不能调，那个也不能，我说你干了多久你就要调，调整后你能确保产生好的效果吗？如果你都不理解，你怎么去调整，所以这是大原则，就像任老板说的，先加话。

第二，如果推荐的话，我就推荐你学习我们华为的HU2E实施框架，你就去学习那个吧。但是我跟你分析一下，scrum这方面，他是框架，所以你看他官方的东西，因为我只推荐官方的，大家公认的大师，不然的话存在权威问题。对于scrum，你看官方的定义和材料，他只讲框架，因为他的几位创始人，坚持讲框架，他不讲scrum怎么做，这就意味着创始人写的书非常的精简，但是你看Michle Kon实际上是实施派的大师，他们的书就非常的厚，这是区别。

对于scrum来讲你看到权威材料就可以了，但如果从scrum中挑人，你最好挑一位实战经验，各非方面都很丰富的，你可以通过看他的博客，看他的视频，跟他打一些教导，看他的演讲等等，判断一下去选人学习。但是实际上所有情况都是类似的，这是另外一个基本原则，你要重视选人。

第三，从知识体系上来说，scrum他的框架很简单，另外一点他，为了保持自己简洁，他只讲人员管理，项目管理，项目管理这三个维度，关于技术的，工程的，实践的，他全都没有讲，他全都留给了你，如果你要学习的话，你就有很多方面要学，从学习的角度我们要理解他的局限。XP是另外一个特点，他创建的时候，就是一个工程派，是实干派，只不过是高级实干派，高级技术专家。所以，他在你具体怎么做事儿上，讲的非常的清楚，可以看看他的书。

但我个人觉得他在提炼性和偏管理维度做的不大好。因为极客不需要管理，但是一个企业有多少极客啊？比如拿华为讲，真的极客需要管理，能够开创一片天地的，没有几个，用阿里P10，用腾讯T4，华为就不讲了，可能是23、24级的，能有多少啊？绝大部分还是金字塔下部的，所以仍然要给他一些具体的要去做，这是他的优势。

我对看板其实是不打认可的，今天就不展开了，看板强调自身持续改进的框架，所以他教给你一些方式去看一些数据，去从这个角度看一些问题在哪里等等。所以从这个角度来讲他其实是一个过程改进的框架，但是这样一来，你要想学好看板，你就必须学好他的案例，不然你不知道在这个场景下，他为什么要改进。如果你只是要去学他那一套方法去找改进，可当你眼前出现一大堆数据，你要去改哪里，根本不知道的。

从认证体系来讲，还有一个叫ICA的，他在中国不是很有名，但他的认证体系是比较全的。他的组织者，创始人可能有学术背景，或者对学术比较注重，所以他按照角色划分，按照知识体系划分，层级划分，我觉得这个结构是非常严谨的，所以你可以参考他的。

此外，还有PM的ACP，它的特点就是他什么都给你，关于敏捷的知识他会全部告诉你，但是我考ACP比较早，我是15年，他进入中国第一测试时，我当时在IBM带敏捷团队，所以我们就先去做了试验田，然后他的问题是，内容多，但比较散，没有主线。所以你从他的参考书，你可以知道敏捷的大盘是什么样的，但是盘子里的菜到底怎么吃，这个菜如何搭配才好吃，他不讲，而且因为它本身的考试学习分开的体系，包括他的商业模式，我觉得对于你学习，还是要挑老师。

基本上来讲，这都是主流的东西了，然后nice的CF也是差不多，你到他的官方，你挑他的老师。我觉得几大体系，单独讲方法论，这些方法论都是看老师，因为有实践经验的老师和只给你讲方法论的老师是不一样的。从知识体系来讲，PMI的ACP他定位在敏捷，而不是方法论，ICA也是定位在敏捷，而不是定位在具体方法论，所以他们更强调知识体系的完整性。但是我觉得PMI的逻辑性和线索行不强，ICA我认为相对知识结构是最好的，但只是在国内不大热门，知识材料比较少，你需要多花费一些经历。如果你不想有这么多烦恼，就来学习华为的端到端HU2E实施框架。

Q（丹阳子）：谢谢老师，那刚才也提到，华为的实施框架和云端元非常的好，在工具方面，有什么意见嘛？

A（悟空）：D-cloud你可以去了解一下，我也讲一下经验，我原来做实践我就不讲了，以前那个年代，自己选择工具的余地并不大，尤其是商用工具采购就比较难，外企比较灵活一点，你用免费的比较好说话，但是要用采购的话，其实也不大容易。后来我做顾问的时候，因为我们讲究方法，不涉及工具，所以我们一般推荐大家使用科技含量的工具，比如说百百便利贴，后来我到华为的银行能力中心，接触了一些更大规模的敏捷实施的时候，我发现低科技含量工具是有意义的，他对协作是非常好的。但是我认为更应该是结合，也就是说不是把物理层面的工具扔掉，也不是说完全扔掉电子工具，而是要结合使用。所以我觉得应该配合使用，结合你的工作流。

另外一点DIE-WEBS这个概念太大了，你也不知道你自己到底讲的是什么。我个人认为，他的发展，KM-book这些他的知识体系非常的完善，讲解的非常清楚，而且只有一个标准答案，外国人跟中国人一样，这就叫标准答案。CMI到底是什么，他只有一个解答。PM项目管理是什么，他只会有一个解答，后来我知道有perance2这些东西，我觉得KM-book要好多了，更贴近软件项目管理。

到了敏捷你就会发现，有各种各样的方法论，没有具体答案，就好像江湖上有各种各样的门派。到了DIE-WIPES你就会知道，鬼知道什么门派，各家厂商都会说我家的DIE-WEBS是这样的，你可以认为他是一个更混乱的场景，所以在这个场景下，当我们没有一个理论的解释的时候，你的边界是不清楚的，你边界不清楚我就很难说，哪些是DIE-WEBS的，以上都是我的一些看法，但并不是说这些解决不了问题。

在业界有两个东西，一个是Extabelex，他做了一个类似于元素周期表的图，里面有很多的工具，当然他把所有的都框进去了，代码的工具，协作的工具，监控的工具等全都包含其中，这个图你可以参考，里面有很多的工具的选择。当然它是按照领域的，比如，协作有哪些工具，缺陷管理有那些工具。

工具主要是这个图比较有名，但当今的趋势，尤其是上云之后，其实他的优势体现在一站式的平台，也就是我能够打通。说白了DIE-WEBS带来的是什么呢？其实我认为，最关键的是，效率的提升。他的核心体系是流水线，大家都是说的从提交到上线，这就是要打通，一定是说在代码上去之后，编译自动的稿，发布自动的搞，这才叫DIE-WEBS，所以一定能打通，这是他的一个特点。另外就是在整个过程中，你所有的的工程活动，全部都有工具，因为工具在使用时，可能这是非IT行业的话，在国家讲，这叫信息化，信息化就是东西都在在工具里面了。

但我们面临的另外一个问题是什么呢？他在各个系统里面，他可能是不同结构化的数据，可能是非机构化数据，总之对不起来，当我们把所有的工具都打通对接起来的时候，这意味着结构对齐了，结构对其意味着标准化，标准之后，意味着HI可以通了，可以微服务等，这种东西是相关的，当你把所有的东西都实现以后，所有的环节都可以用数字来表达的时候，这就叫数字化。这才是真正的DIE-WIPES，你可以实现最后所有一切都叫代码的主张，当然就容易对接。

工具的找到和你的研发分期是相关的，你的整个工程活动，从用户提出需求，到上线之后，用户有反馈，这个中间哪个环节是最慢的，那你就先结局这一部分，先就觉有工具，再者就是工具有效率，工具有联通，一步一步解决，这就是你搞DIE-WEBS的基本思路。

问答六：

Q（三舅）：老师，我有个问题，就是你刚刚也提到过，在你眼中，事事皆可自动化的吗？其实我也在做工程，我也体会到，让一切自动化是很有难度的，所以在我的记忆力，一些UI的测试，在你的角度来说，您觉得这些测试也要自动化嘛？

A(悟空）：我要双三个点，一个是为什么要自动化，第二个是UI，第三个是探索。

第一个是为什么我要自动化，或者我为什么坚持100%自动化。这不是可能不可能的事情，这绝对是可能的，你想人工智能都可能的话，怎么可能不去自动化，人工智能背后的前提就是自动化。另外的话，早几年前我还在测试领域，虽然我主要是做教练和顾问，但是我讲的一个材料中提到，连刀削面都有机器人了，请问还有什么可以不自动化。富士康都一堆机器人了，你还说不能自动化，你以后还吃这碗饭嘛？所以我觉得自动化，是没什么好讨论的，无非就是代价。

以前我们在通讯的时候，要发流量去压设备，AXT-4000是发送流量的，我对解不了，因为我们当时主要用的是PYTHON的工具，写TIKO啊，后来他们解决了，用TIKO去解决，我照样把python掉TIKO，问题照样解决了。反正，没有什么是不能自动化的，只是说你的投入成本，你觉不觉得划算，所以到最后，他是一个经济选择，我要做前期的设备采购，人员的培养或者什么东西，或者工具的采购，我实现以后能带来多少的效益，这是实际情况下要考虑的。如果我们只是谈原则的话，这绝对都可以自动化，只是你需要去判断，这需不需要。

另外一点，我后来在互联网崛起的时间，圈内有很多很多的讨论，那时候讨论的是，我们不需要测试，开发认为我不需要测试，我测试啥，我不需要，真的不仅仅是吵架，因为有很多朋友在互联网企业还没有工作过。我是在诺基亚，惠普，IBM，华为，辅导过互联网企业，你不要告诉我，互联网不是这样子的，因为我确实没有在互联网工作过。所以它的特点是什么呢，我朋友在互联网工作，他就讲，我们的代码在上线之后，他是混敏捷圈儿的，我说你怎么不写单元测试，不写ADD啊？他说我们的代码上线之后，监控非常厉害，一旦发现苗头不对，回管过来，让我改，我写测试，立马上线，回管过来，我不写测试了，测试都不屑，还要搞自动化吗？这些都要看情况，但我始终认为，互联网的人也把测试看的太简单了，因为实际上，你测试的重要性和难度性是跟你的被测系统有关的，被测系统是里面最重要的概念，对吧？那你的被测系统决定了你的测试难度和要不要做出这个投入的产出比，当然这对开发背景的人来说，不大好理解，因为你开发背景，不一定学习测试理论，不一定知道有被测系统这样一个概念。

那什么样的情况下，测试是很重要的呢？就是你这个产品最终所需要服务的用户，它使用你这个产品时候的心智模式，和你这个开发人员，在你开发业务功能时候的业务模式，两个到底有多接近，你对于很多互联网业务来讲，什么叫互联网业务？实际上互联网业务其实从本质上讲他是一个消费者业务，你说我也是一个消费者，我当然也能理解消费者了。虽然我写的是代码，但我功能是理解的，我可不可以测试？我当然可以测试的，我想想就会知道这个用户可能会做什么。但是请问，你可以搞个ERP系统来试试嘛？你有管理过工厂吗？你有管理过财务嘛？你有管理过反洗钱的操作嘛？你根本就不懂这些，请问你怎么测试？你写出这样一个系统，国家敢不敢用啊？

所以测试的重要性真正在于产品的使用者的心智模式和开发者的心智模式，两个有多大的心里差别。说白了，用代码的语言就是你生产代码语言的生产者和消费者是不是一致的。你写一个简单的函数，写一个简单的HI，写的大家都可能不会用了。所以你说测试哪儿有那么容易啊？

第二，UI测试。我认为他是在测试圈没有解释的，我认为没有白盒，黑盒，我觉得他的区分就是扯淡，然后回到这里来讲，我认为被测系统的划分是什么？UI测试，你到底在测试什么，而且这个词儿就有问题，命令行也是UI，触控屏也是UI，所以大家都说UI不好测试，说的是PUI，图形用户界面，但是这个时候我们就要区分开，到底是测逻辑，还是界面啊？你测逻辑的话，那你为什么一定要通过界面来测试？难道的API没有逻辑，不能调用它来测试，一定要通过界面来测试？你的开发人员一定是要被打屁股的，这是一个问题。另外，当你真正要测试UI的时候，为什么要写自动化测试？这个投入和产出很重要吗？另外你为什么要自动化？所以，我觉得这是UI测试必须要有的一点。

当然我也知道有一个现象，很多人会说，我不通过UI，测试不了，你这个经历可以拿到下面解决一下，远比你这样做好多了，你的代码变得更容易理解，更易于维护，也更易于测试，架构也更良好，比你在测试端解决要好多了。当然能否这样解决问题，真的很难说，因为我不知道有多少人是开发背景，或者是研发经理。很有可能研发出身的人，他很赞同，可跟开发经理说，你扯淡。

回到本质来讲，很多都不是技术问题，就是技术问题已经在世界上被解决了，问题是当你拿着问题的解决方案去跟另一个人讲的时候，他会跟你说，我觉得你讲的不对。那你想怎么解决呢？我来。又回到了先前说的，如果什么都是你解决的话，请问你是测试还是开发？回到一开始，你的根本和本质，需要通过协作来解决问题，我们知道怎么样才是解决问题的最好根本方式，这是一回事儿，同样让大家接受，认可，一起来用这个方式做问题，这才是另外一个问题。

所以，UI测试你首先要分清楚，你到底要测试的对象到底是什么？并不是说你的UI是你的被测对象，还是UI是你的测试手段，是要测别的东西，如果是你的被测对象，那你就要区分清楚，你就把下面mooke掉。你就只是在UI层输入输出不就完了嘛？你不需要真是系统。如果UI是你的手段，那我可以换一种手段，我为什么要做这么高开销的手段，这不就是我们所说的事倍功半。

第三，探索性测试的问题。我觉得国内很多人理解错了探索性测试，探索性测试很多把用自动化和手工来区分，这本身就是有问题的，实际上他不在于你做什么，在于你脑袋里面想什么。所以你再思考一个方向不确定，或者是你也不知道自己想得到什么的时候，你可以做一下探索性的测试。比如说哥伦布，他知道那边一定有东西，但是我也不知道他在哪里，我也不知道要多久才能到达，这叫探索。

软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。