敏捷实践(6) - 一个缺陷的成本是多少？
不管承认与不承认，IT项目开发过程中，开发人员每天都在生产缺陷，那些没有自动化单元测试、功能测试、集成测试、验收测试的团队更是如此，简直可以用开发人员每日努力在产生缺陷。
这个情况与是用传统项目管理还是与敏捷过程管理无关，因为即使是用敏捷过程，只要没有大力应用自动化测试(TDD, XP), 也好不到哪去。
回顾我之前在的W公司，那是公司使用dotNet为银行开发财富管理平台，传统项目模式的强矩阵管理，清晰的角色分工：
- BA做业务需求分析，输出FRS
- Architect根据FRS, 输出架构设计指导
- DBA设计数据库与DTS
- Dev Team(Team Leader, Senior Dev, Dev, Junior Dev) 编码实现
- Test/QA Team 打包部署测试
项目周期内部开发测试6个月，SIT 2个月，UAT 2个月，共10个月。上线后做项目评审，这个项目10个月的时间里，QA有记录在案的大大小小的缺陷就有一千六百多个。上线后仍有将近一百来个作为已知缺陷Go Live~.
再后来的Z公司，三个多月赶出一个APP，Bug List上有两百多个。上线后又持续花了三到六个月再改改改，大部分时间在改Bug，新功能仅占小部分。
这个事情也后来我一直努力推行测试驱动开发的一个主要原因。
一直以来我们都知道缺陷给项目造成巨大的影响，进度问题，返工问题.....甚至导致项目最终失败。
但是我们也没有清晰的去评估一个缺陷的成本到底是多少，直到前段时间在我们CSM聊天群里谈论到这个问题，才有一个比较直观的方式分享给大家参考。大部分信息来源出自我们的教练CST Ethan Huang。
缺陷的处理过程与时间成本:
发现一个bug后的活动至少有：
- 使用工具记录bug+跟踪； 2小时
- 本机修改bug； 2小时
- 开发环境验证； 2小时
- 测试环境验证； 2小时
- UAT回归测试（可按单个bug验证x10算）； 2小时 x 10 = 20小时
- 以及部署; 2小时
共6个环节, 共30个小时, 约等于 4 人／天。
解释一下，为何UAT回归测试要按单个Bug验证 x 10
回归测试按水波效应最少影响十个测试用例
那么做一次回归测试等于做十遍单个测试用例
按照一次回归解决所有问题，且问题不再重现的最美好情况
水波效应是指从测试逻辑上讲有影响到的功能
比如你在放入购物车这个功能产生了金额不对的功能
那么改掉后你光测购物车的金额是不够的，还要测check out、付款等下游功能
一个人天的成本:
在北上广深，人均月成本在5万左右，人均月成本包括（工资、社保、福利补助、奖金、办公场所、设备折旧、行政财务均摊等等），是在公司角度计算，而不是仅仅个人工资支出。
据说，这个水平是北上广深的平均水平，有高于这个水平的公司，也有低于这个水平的公司。具体数字可以找公司的人事部门获取。
两个重要数据出来了，我们可以直接计算出一个缺陷的成本是多少了
平均一个月按照20个工作日来计算
一个缺陷 = 4人天 x (¥50,000 / 20天) = $10,000
也就是说，平均一个缺陷造成的成本就是
一万块, 一万块, 一万块
特震撼有木有？ 我刚计算时也被震惊了，居然有这么多。
然而，然而，如果再加上机会成本(时间用于改BUG，就无法用于开发功能)的话，这个数字就要翻倍。
大多数情况下，公司也不是按照这个方式在100%承担这个成本，例如，
当团队每周产生足够多的BUG时，这个BUG总成本也就是降下来的，因为BUG批量处理起来效率也会比单个单个高。
又或者，当某个功能BUG太多时，有可能会把这个功能砍掉，BUG成本立马为零了。或许，推到重来，也可以把BUG丢掉，只不过新实现还是绕不开这个问题啊。
还有一种更严重的情况，那就是需求缺陷，由于需求出现问题，导致某个功能甚至整个产品方向需要做重大调整，这个造成的成本更加巨大。
开发人员制造的缺陷，成本是以万计；
产品经理/产品负责人制造的缺陷，成本则是以十万乃至百万计。
在后面，我们推行敏捷过程，努力实行各种自动化测试与持续集成来确保质量，对质量问题不妥协，质量与进度同等重要。我们也在享受着相应的回报，开发人员不再疲于改bug，改一个bug的同时引入三个bug，有效将力量用于更有价值的功能开发。
不管敏不敏捷，都需要重视质量问题，最好的办法就是将所有数据转换为相应的钱的数额，既直观又有动力。
最后，评估一下自己公司的情况，我们不妨做个生意，我帮你们改进流程、提升开发质量，一年时间至少减少100个Bug，按100个Bug成本100万计算，省下来的这100万，40万给公司，10万给团队做奖金，50万给我😊😊😊😊。 同时公司还收获100万的机会成本。
Win-Win-Win. 想想都美好，哈哈哈····
