1

敏捷模式之对外 — 求快、求生存。

一方面：是整个大环境在发展，市场竞争厉害

一方面：作为企业的一种自我焦虑和不确定性

比如：要快速地发布，不然别人就发布了这个功能，我会失去这个先机。

别人都有这个功能，我们也要有，如果没有就会被用户和市场抛弃。

真实：用快速的迭代来掩盖需求上的不确定性。用快速的迭代来减少错误带来的损失。

而用户的需求一直没有变过：

1）帮我省钱/赚钱

2）帮我省时间

3）给我带来娱乐

4）教我进步/跨越障碍

2

敏捷模式之对内 — 求效率、求质量。

首先敏捷是一个迭代的过程，那么可以迭代成功的基础是前面一次是对的，这里追求的就是一个功能的稳定。

而每一次迭代新的功能会不会对已有的功能带来影响，有什么样的影响？其实研发自己是知道的，如果他说不知道1）他能力不够优秀 2）他没有时间去证实 3）对方不曾相信他的知道。

从人性的角度出发：要让别人相信，最好的方式：有个第三方来证明。（或许以后区块链技术也会用于这里-去掉中间的第三方。）

回想起软件行业刚发展的时候-是没有软件测试的，研发都是一个人完成所有的，为了让自己有更多时间花在专业上（研发），或者是为了避免个人思维的局限性，于是将不确定性专门给另一个人来做，而这个人不需要很高的技术就能完成80%的验证，如此低的门槛，而市场需求量大，软件测试行业蓬勃发展。

敏捷模式的迭代，功能像滚雪球一样越来越大，每一次发布前要做的验证越来越多，需要投入的测试成本逐日递增。

版本一：星期五上线，星期三研发新功能10个去需求点待测试，测试可以在周四的时候就完成。

版本二：星期五上线，星期三研发新功能10个去需求点待测试，上一版本10个需求待回归，测试可以在上班时间完成。

版本三：星期五上线，星期三研发新功能10个去需求点待测试，上一版本20个需求待回归，测试稍微加个班可以完成。

版本四：星期五上线，星期三研发新功能10个去需求点待测试，上一版本30个需求待回归，测试加班加狠点可以完成。

版本五：星期五上线，星期三研发新功能10个去需求点待测试，上一版本40个需求待回归，加个测试可以按时完成。

······

一家公司通常不会在底层说人手不够的时候就立马增加人员的。

它加人的起点是：多一个人带来的利益有多大，是支出的多少倍（多一个人多付一份薪水）。

不断地回归测试 - 实质是一个确认性的工作，而不是创造价值性的工作。

公司不愿意加人，员工已被工作量压的直不起身，会抱怨：我又不是机器人，可以不眠不休的工作。

公司考虑的是：员工不是机器人，但是如果有机器人可以自动来做件事情那该多好，还不用付薪水。

由此可见：自动化测试，这一需求，第一个想要的人：是老板；其次：才是苦逼的测试。

一些技术人员/测试人员发现这个痛点，研究和折腾出很多框架，来应对老板的需求/解决他的问题，老板也愿意付高于普通测试的薪水-为新技术/模式买单。

所有普通测试发现这是一件即能解决自己繁重工作量，又能提高自己待遇的事情，也愿意去学习自动化测试技术。

项目经理也很高兴，想象着有了自动化测试技术，我的新版本上线时再也不愁啦，时间成功和人力成本都会降低，简直没有比这更好的事情啦。

一下子出现了个皆大欢喜的局面，用专业的话来讲：双赢。