昨天晚上和部门的几个SC在新加坡项目现场聚餐, 期间有个资深SC问我: 我们不是已经敏捷了吗? 敏捷到底是什么?
上面说的'我们已经敏捷了', 指的是2017年初开始EBS项目作为公司的试点项目, 自上而下开始推行的敏捷转型. 这位资深SC因为长期在项目现场, 未参与母公司的敏捷导入培训, 也没有参加后期的敏捷教练训练营, 问的是合情合理. 其实就算参与了公司的导入培训, 我也观察到很多研发的同事在这个问题的理解上还不算清晰. 比如, 敏捷就是Scrum吗? 有了站例会和看板是否意味这团队就开始敏捷了? 作为一个早期参与到敏捷转型实践的员工, 结合最近看的一些书籍资料, 写一些我的理解.
首先, 用排除法. 看敏捷不是什么:
敏捷不是方法论, 不是特别的软件开发模式, 也不是一套工作框架和流程.
也就是说敏捷不是一个可以生搬硬套的理论和流程. 比如, 它不像一个编程语言, 有一套固定的语法和语义. 也不像一个工作流程, 只要按照流程图走, 就可以到达终点. A公司的敏捷实践不一定适用于B公司, 也许实践起来有诸多矛盾之处. 假如你在市面上看到有推销XX公司敏捷方法的书籍或者咨询公司, 比如IBM敏捷, 微软Scrum, 等等, 建议你三思而后行.
敏捷是一套价值观(values)和原则(principles). 我们谈论敏捷时, 经常会谈到具体的实践(如站会, 回顾会), 甚至具体的工具(如Leangoo). 然而这些实践或工具本身并不是敏捷, 而是用来让团队去贯彻敏捷的价值观和原则. 换句话说, 只有当具体的实践/工具带来的效果符合敏捷的价值观和原则, 它才是敏捷实践的一部分, 理解敏捷价值观和原则是用来帮助我们在研发过程中做决策.
这么去理解敏捷, 就会发现在敏捷实践中, 每个团队/项目/公司所采用的方式可以是非常灵活的.
现在来看看这些价值观和原则, 也就是所谓的敏捷宣言(agile manifesto), 包含了4个核心价值观和12条原则.(http://agilemanifesto.org/iso/zhchs/manifesto.html)
4个核心价值观:
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动高于 流程和工具
工作的软件高于 详尽的文档
客户合作高于 合同谈判
响应变化高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
注意人们在阅读时, 经常喜欢划重点, 而忽略了很多其他关键信息. 如敏捷宣言的前两句.
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人
两个关键字: '实践中探寻', '同时也帮助他人'.
强调了敏捷除了实践没有捷径可走. 也强调了敏捷不是一个人的事, 只有团队的敏捷才是真正的敏捷.
还有最后两句(比起前两句, 这后两句话现在被强调的次数更多):
也就是说，尽管右项有其价值，
我们更重视左项的价值。
这里强调了右项不能被忽略, 但是在决策时, 如果最后决定更符合左项价值观, 应该如何行动.
12条原则:
我们遵循以下原则：
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
以上每一条都可以通过阅读专业书籍来解读, 这里不累述.
举例来说如何理解并参考敏捷敏捷价值观和原则:
比如,当开发人员接到一个任务时, 他发现如果设计一套规则表, 不光可以解决现在的问题, 还能更灵活的支持其他复杂场景. 但是开发工期可能要延期1周. 当他考虑到'及早交付有价值需求', 以及'以简洁为本'的原则, 他会找需求负责人谈, 是否这个场景未来会经常变化? 还是特殊业务? 客户对版本交付的时间敏感? 而不是自己直接做决策.
又比如, 测试人员原则在做UAT, 现场网络很差, 准备数据要花半天时间. 考虑'激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标'的原则, 团队负责人应该第一时间解决网络问题.
再比如, 需求分析人员经常出差, 无法在所内办公, 考虑'业务人员和开发人员必须相互合作，项目中的每一天都不例外'的原则, 团队负责人应该考虑如何增加需求分析师, 或者和客户说明需求调研必须在某个时间段完成(当然这个也不符合'欣然面对需求变化'的原则, 在公司合同约束的前提下很难改变, 当然也应该是我们努力改变的方向), 留出与开发人员沟通的时间.
当所有的团队成员(需求,设计,开发,测试,甚至到交付)每天的工作都以敏捷价值观和原则来作为决策基础, 持续改进, 假以时日,这个团队可以自豪的说我们已经在走向敏捷了.
