2017.6.14, 深圳, Ken Fang
产品开发会失败, 而使企业陷入运营的危机, 不外乎两个主要的原因: @ 滥用敏捷 @ 将团队成员引導到只專注流程、审计、模版; 而完全忽视客户与产品对客户的价值
我们对敏捷最大的误解便是: @ 认为敏捷就是快 @ 认为敏捷就是早上提需求, 下午就要有结果 @ 认为敏捷就是可在需求的目的, 范围都不清楚的情况下, 就可进行开发 @ 认为敏捷就是可任意的变更需求的目的与范围
试想, 假如敏捷可以早上提需求, 下午就要有结果; 可在需求的目的, 范围都不清楚的情况下, 就可进行开发;敏捷就是可任意的变更需求的目的与范围… 那即使我们是按照敏捷项目的管理方式; 也就是说, 按照团队有多少开发人员、测试人员, 迭代周期有多长, team backlog 就有多少工作量。但这样即使是按照了敏捷项目管理的方式, 就能保证产品软件架构的一致性? 代码的可维护性?
我想, 这也是目前许多只知采用 Scrum/ KANBAN 的团队, 随著产品代码行数的增加, 在开发产品的效率与质量上, 却一路下滑的主要原因。
也就是说, 只要是开发产品; 不论是不是互联网企业的产品; 该做的事, 一件都不能少。 Amazon, Google 开发任何一款产品前, 往往都是在连使用者是谁都还在探索. 但, Amazon, Google 绝不会在连需求的目的、范围都不清楚的情况下, 就进行产品的开发. 更不会在只是凭一句话, 就变更需求, 更别谈变更需求的目的, 范围了。
所以, 真正的重点是, 我们不应、也绝不能偏离开发成功产品的主航道。
开发成功、有价值产品的主航道, 主要是由三方面所构成: 1. 以人为本: 开发产品是社会工程; 讲求的团队成员的自主、协作与能力。 2. 以产品架构为緯: 产品要能快速的响应市场的变化,要能快速的满足客户的需求, 靠的绝不是敏捷, 靠的绝不是 Scrum/KANBAN, 而是软件架构; 可水平扩展的软件架構。 3. 以纪律 (discipline) 为经: 要做出有高水准的产品, 绝不是忙与盲的在做变更, 而是要能根据市场的变化、客户的需求, 做出最适合、最有效的决策. 而最适合、最有效的决策是来自于 “纪律”. 所以, 当前业界都是将敏捷与软件工程结合; 由敏捷提供社会工程实践的方法, 由软件工程则提供纪律。
