写在前面
- 这是一个在2016年举行的2015敏捷之旅。
- 我第一次去，活动地点不好找。出地铁站碰到一位急匆匆的妹子在问路，不好意思把她当成了人工GPS，她在前面小跑问路，我在后面跟着。我本来想邀请她一起找路的，奈何妹子跑得太快，又素不相识，没好意思拦截。
- 时间不够。几乎每场都是超时的，尤其第一场，大概讲了一半就草草结束。
- 主讲的都是专家，本身挺有料的，但每个人演讲水平不一样，或者对听众需求把握不够准确，在演讲过程中，大厅的留言直播小屏里竟然出现了吐槽，什么“要干货不要忽悠、不知道在讲什么”之类。不知道专家有没有看到这些负面反馈。我想如果我是演讲者，在台上面对屏幕看到现场这样的批评，估计舌头都要打结了。还有吐槽主持人水平不行的。主持人是小姑娘，好像是志愿者来的，只是串场介绍嘉宾，不知道那些高要求的吐槽帝是怎么想的。
下图是主会场流程，下午另外开有两个分会场。我一直呆在主会场，一天下来，晕乎乎的，脑容量不够用的感觉（可能是听的太专注，脑子缺氧）。
进入正题
有一段很有哲理的话大概是这样：一本书、一场电影很精彩，看完以后，过了很长时间，我们无法记得全部，但如果仍有一句话一段台词深深打动了你，改变了你的想法，那就是那本书或电影带给你最大的收获。
对于讲座来说也是一样，我无法记得所有内容，但每一场我至少收获了一个关键词，而且每一个关键词的后面都有大段我对它的消化。
第一场，关键词：5 Why分析法
苏于登讲了一个他如何用敏捷方法使一个银行项目起死回生、最后大家升职加薪皆大欢喜的案例。我印象很深的是使用5 Why分析法诊断当前项目流程中存在的问题。
首先，把当前项目从需求到上线所经历的所有流程步骤可视化，并划分出问题的界限，即我们有权限改造的范围在哪里。如下图，如果软件中心是我们改造的范围，那我们只针对软件中心的流程做诊断。
其次，把每个流程步骤所在进行的工作内容可视化。如下图，可以借助工具以看板的形式列出工作内容。
审查每个流程步骤、每项工作内容，找出异常及问题所在。如下图，看上去是“项目经理确认”的环节出了问题，项目经理前面的开发环节，一大堆任务在处理中，而项目经理好像无事可干。
最后，用5 Why分析法探询问题本质，从最表层的问题问起，抽丝剥茧，最多5次发问，找出问题产生的根本原因。
一个产品或一个项目的开发运营，需要需求、设计、开发、测试、运维各环节的团队成员配合，当问题出现时，到底是自己的原因、他人的原因、工具的原因还是协作的原因，每个人从自己的角度好像都可以找到合理的解释，争论下去甚至会发展到推卸责任、互相指责的地步，这个时候纠结于个人立场的表述无异于雾里看花。作为团队leader应当保持清醒的头脑、理智的分析，而5 Why分析法就是一个引导团队找出问题产生的根本原因的好方法。
这里还有一段小插曲。活动结束后第二天，大会微信群里有一个朋友现学现用，按上述方法，对他正在进行的一个项目的流程及内容作做了可视化，果然发现很多坑。 在大家的鼓励下，他发问了N个Why，层层分析，最后绝望的发现是组织结构、公司体制的问题。
这个时候怎么办？
我想为什么是5 Why，而不是6 Why、7 Why、N Why，是有一定道理的。除了5个Why足够找出原因外，另外，5次发问它在一定程度上限定了提问者的天花板，即有限次数的提问可以把问题的解决限定在提问者力所能及的范围内。问太多，发现是公司的问题、老板的问题，不是没有意义，但可能不是在提问者有能力和权限去解决的层面上。如果我是那位朋友，我会把我的发现报告给我的直属领导，但不要期望或消极等待上级、老板去解决问题，我会在我的5 Why范围内投入我能推动的资源去解决我所在层面的问题。
第二场，关键词：Feature team
潘瑞英来自腾讯，她介绍了腾讯开发团队采用的一种敏捷组织模式：特性团队（feature team）。
特性团队要求团队围绕软件或产品的某项可交付的端对端的特性来组织开发，团队成员的构成是跨职能的，而且是长期的稳定的组织结构。举例，一个做网站开发的特性团队，开发、测试、运维、数据库管理员都在同一个团队里。相对于职能团队或组件团队来说，特性团队的成员协作更紧密，沟通更顺畅，它直接面对“客户”（特性的使用者，有可能是使用产品的客户或者其他接口团队），它快速高效地响应客户、市场、行情的需要。
腾讯的产品如QQ浏览器、微信安卓版等就是按这种模式组织开发的，他们把同一个产品内上百人的开发团队按产品特性拆分成多个每个约15人左右的特性团队，每个小团队针对特性进行快速迭代，每次的迭代周期完成后，再合并回主版本。
潘老师是从腾讯大产品的角度来介绍特性团队，对于创业公司小团队而言，如果引入敏捷开发，其实开发团队的构成天然是特性团队的模式，而团队针对的所谓“特性”其实就是整个产品。
第三场，关键词：扁平化组织
莫敏介绍了敏捷在腾讯游戏开发中的应用。其中一项讲到了他们团队中的扁平化组织结构，我印象比较深刻。
一个腾讯游戏开发团队的扁平化组织结构大概如下图。
可以看到大家都是靠技能吃饭。我在公司跟团队开会做分享的时候，提到了全栈工程师，多技能学习的问题，其中一个同事随口说了一句：到最后都转管理了，哪还学那么多技能啊。我用这张图反驳他说，互联网公司，无论大到像腾讯，还是小到刚成立五个指头可以数完人的创业公司，在扁平化的组织结构（开发团队）里没有职业经理人的角色，尤其是在敏捷团队中，为了应对快速变化的需求、缩短开发周期、提高推出频率，大的团队要拆分成小团队（当然不是绝对，但如果要选择比较好的实践的话，这是推荐的做法），在这种小团队中，没有职能经理发号施令的空间，相反的，全栈或半全栈拥有多项技能的开发工程师更为吃香。
现在常常提到互联网思维对传统企业的冲击，这是很实际的一个问题，互联网公司、敏捷团队的扁平化组织结构对于传统企业来说是一项必须直面的挑战。
第四场，关键词：敏捷是一种文化
李小波是深圳湾的联合创始人，他说敏捷是一种文化。在深圳湾，他们提倡自组织、自管理型的团队，在这样的团队中，要给成员充分的信任，营造开放、充满激情与创意的工作氛围，听起来很facebook、google的感觉，当然，对人才选拔、员工的素养要求也会比较高。
既然是文化，就会引起冲突。他举了个例子，说深圳湾后来新加入一位联合创始人，来自于国企。他们之间就不同的公司管理理念产生了一些诸如命令与信任、服从与激情、层级与开放的冲突（其实就是传统企业文化与敏捷文化的冲突）。
但这并不是一巴掌拍死的坏事，来自于国企的这位联合创始人与他之间的这种冲突，对于公司文化是一种平衡，这些冲突最后都展现为一种融合，让他在公司推行敏捷文化时，仍然维持着恰当的约束，避免团队组织走向散漫无序的极端。
第五场，关键词：敏捷转型的关键在于搞定人
蒋毅举了一个IBM团队转型敏捷的例子。他早期作为一个测试工程师，成功参与了一个IBM内一个小团队的敏捷转型试验。上头一拍板，big bang！决定参照成功模式，对一个500人的团队进行敏捷转型。结果经历了大半年混乱无序、充满抵制、怨言的痛苦转型过程。虽然最终还是完成了转型，但是过程剧痛， 走了弯路，浪费了很多资源。
一个大组织中，每个人都有自己的诉求，每个人面对问题的层面不一样。对于敏捷的转型，大家有没有统一的目标，大家怎么看待敏捷对个人对组织的影响，有没有共识？这是转与不转，需要认真思考的问题。
有一个参会者诉说了他的苦恼，他想在公司推行敏捷开发方法，但每次开会讨论，大家都不积极，好像有没有敏捷都无所谓，去开会纯粹是为了应付leader的要求。
蒋毅给他开的药方是，先问问自己一个问题：你为什么要采用敏捷，如果不用敏捷，你目前的开发团队有什么问题？搞清楚了敏捷的目的、确定敏捷可以解决团队所遇到的问题后，然后要询问每个团队成员的诉求：你个人目前碰到的问题是什么，你想解决什么、获得什么？作为leader，需要把敏捷可以带来的好处，短期的或长远的，落实到个人，打开团队成员的心结。
第六场，关键词：DevOps不是工具，是方法
我是第一次了解DevOps，绝大部分参会者也是第一次知道这个概念。刚看到这个单词时，我以为DevOps是一种工具或一套软件。其实它是关于开发与运维（Development+Operations）如何更高效地协作的方法。它是一个概念、方法论，就像“敏捷”这个概念一样，它指的是团队组织某项活动采用的过程、方法，甚至文化与思想。
一个项目的开发流程会包括：需求、设计、开发、测试、部署和运维，如果一定要严格的划分DevOps解决的是哪个阶段的问题，我们可以把它归类到开发到运维这一个过程。在传统方法上，开发到运维划分为不同的职能，权限上有严格限制，沟通与协作上存在很多壁垒。而在现今的互联网环境中，一方面要求对产品采取更频繁的变更与发布，另一方面又要满足部署与运维对生产环境要求的安全性、可靠性与稳定性。而DevOps提供的就是这样的解决方案，即满足频繁变更发布的要求，又保证整个生产系统的安全及稳定。
据说，在DevOps的帮助下，一个大型产品可以做到单天上十次的发布。当然，这不是一个标准，就像项目管理理论提倡的那样，适合自己的才是正确的，任何标准的方法或理论对一个组织来说都不是完美的，要为不同的产品、不同的团队、不同的公司文化做适合的剪裁。
作者：阿蓝，一个女儿的宝爸。个人公众号【一步成长】（ID：alanwriting）专注于“个人认知与能力的提升、自我的发现与成长”。如果您对如下领域也感兴趣：“能力提升、写作、个人成长、亲子关系”，那我们有相同的爱好，欢迎你关注和留言，谢谢！
