反思：别被敏捷忽悠

转自：http://www.infoq.com/cn/news/2014/02/agile-rethink

反思：别被敏捷忽悠

做者 崔康 发布于 二月 13, 2014

• 开发自测不足——新功能都开发不过来，自测随便意思一下就行了。
• 迭代发现的一堆Bug不改——产品仍是过渡期，说不定集成测试前BUG就消失了。
• Bug不须要改——我刚和产品沟经过了，需求变动一下就行了。
• Bug无效——我代码就是这么实现的嘛，这么处理也没什么很差。
• Bug挂起太多——你看看市场竞争这么激烈，每一个Bug都深刻判断咱们哪有时间。
• 发布产品已知Bug很多—— 迭代发布产品有些遗留Bug很正常，慢慢优化嘛。

据dylan所说，其领导的团队采用了旁敲侧击的方法提高研发质量，好比帮忙开发便利的自测工具、合做分析代码覆盖率、冒充用户上论坛投诉、拿竞争对手的结果来刺激团队等等，但始终是治标不治本。

回头再看看，全部掩盖在敏捷研发过程当中的漏洞，日积月累，最终仍是会由整个业务团队来承担苦果。因此时常在想，敏捷研发理论是否被神化了，是否常被错误理解而让不职业的现象层出不穷？敏捷不是新的研发理论，只是项目管理的一种形式。

 他认为，瀑布研发和敏捷研发没有本质不一样，理由以下：

• 是迭代发布的周期不一样？某些互联网产品的版本发布周期一点都不短。入口级的移动APP动辄上百人的团队，规模比多数PC软件团队还大。
• 是有云和没云的不一样？不少行业的后台（云架构）比通常互联网公司复杂多了。
• 是收费和免费致使的不一样？传统行业也有不少免费软件。互联网的有些免费软件比传统软件质量要求更高。
• 是对产品迭代发布的质量要求不一样？
• 是对文档的要求不一样？

结论就是，没有一个要素能真正把互联网和其余软件领域区别开来，因此dylan认为：

瀑布研发和敏捷研发没有本质不一样，，更别说谁好谁坏了，只是由于行业竞争的不一样，看起来交付节奏不同而已。节奏和软件研发的传统精髓没有关系。

除此以外，dylan还批判了常见的几个敏捷误区。刚毕业的学生进入公司要怎么培养？dylan建议2-3年的职场新人不要学习任何敏捷流程的理论：

• 测试岗位的就好好的把一个功能设计出N种场景，使用各类工具反复测试找敏锐感。
• 开发岗位的不是要尽快实现一堆功能，而是先充分理解架构，而后对提交的每一行代码负责。
• 产品岗位的多体验产品多接触用户，头几年最好脱离QQ的关系链，锻炼发布独立产品的能力。

总之，dylan认为，入行新人要学四个字——职业操守，刻在内心，打好基本功，将来无论在什么项目都会受用。

另外一个误区，dylan认为是“沟通比文档更重要”：

这句话看起来有道理，若是你是几我的的小团队，若是人员稳定，功能模块比较聚焦，生命周期也不太长，也没客户找你要什么手册，确实不须要写什么文档。

可是若是你是如下状况的团队，dylan认为文档可能真的比沟通更重要：

• 团队人数数十人甚至上百。
• 项目生命力长，每一个版本都有新功能，模块愈来愈多，愈来愈复杂。
• 异地团队，合做研发。
• 有外包，合做方团队协同工做。
• 团队职业化水平高低不齐。
• 团队不太稳定，或业务归属部门不太稳定。

dylan特地列举了几种缺少文档的糟糕状况：

• 某产品经理忘了半年前的某个功能的具体逻辑，寻求测试同窗的帮助。
• 某开发参加高职级晋升，手上没有一个像样的软件架构图，拿着测试同事梳理的逻辑架构图去评审。
• 一个严重Bug的坑在N个项目组被踩了N次，修复每一个Bug后的注释只有几个字。
• 跨地域的团队，或者先后台的团队之间，发生Bug时互相争执半天，讨论谁该负责修复Bug，彼此不熟悉对方的内部逻辑。
• 至于没有参考文档致使测试投入浪费的事就太常见了
• 公司业务调整，跨部门和跨地域的业务交接不太愉快，交接效率低。

第三，dylan认为不要“边重构，边生活”：

之前公司的开发，30-40%的时间花在概念设计和架构设计，30%在细节设计，10%在编码, 20-30%在代码自测。编码自己只占不多一点时间。技术总监这样教育新人：你不是coder，你是designer！coder是比较低级的工做，软件设计才是高端活。

任什么时候候的思考，对于架构的投入怎么充分都不为过。微信发布那么多版本，这两年重构可能几乎没有。这须要有人尽早思考清楚将来作朋友圈，作开放接口，作插件化等等，开发知道了将来要演进的形态，在一开始就有所规划，预留接口。不然，今天决定要作SNS，重构一次，明天要作插件化，再重构一次，后天做开放平台和公共账号，再重构……对公司来讲就是个噩梦了。

最后，dylan强调，不要存在“迭代版本的BUG多一点是正常的”的误区：

每一个交付到测试团队的产品，必须是可测的，自测过的。不可测的版本就不叫交付。对于可测内容追求在一段时间周期内，尽量高质量的发布，是修炼职业操守的目标，更是精品团队的目标。每个挂起的有效Bug都须要确认：为何改不了？何时改？对发布影响如何？

若是因市场形势必需要尽快发布，至少遵照一个底线：严重Bug必须整改并且优先整改。所谓严重就是可能让用户抛弃你的问题：速度慢，卖点明显不如对手，卖点没法正常使用，不稳定，可能给用户带来额外损失（手机系统，安全，帐号，费用等等）。这样的发布还不如不发。

随着敏捷开发在IT行业的深刻推广，敏捷的优势再也不被业界无限放大，而更多的社区声音开始讨论敏捷的正反两方面，dylan的观点能够给读者朋友一些不一样的启示和借鉴。