首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >正本清源——敏捷的为什么

正本清源——敏捷的为什么

作者头像
腾讯云 CODING
发布2020-04-27 10:09:23
3080
发布2020-04-27 10:09:23
举报
文章被收录于专栏:CODING DevOpsCODING DevOps

接下来进入第一个话题,唯一不变的是变化。大家可能都看过这样一个图:

我们可以思考一下,敏捷这一概念究竟存在了多久?如果追溯历史,我个人认为可能真的可以回归到远古的时代。进化论里的一个经典推断就是:物竞天择,适者生存。那么“唯一不变的是变化”就是指怎样去更好的响应各种无法预测的变化。

如果用一个大圈来表示大自然,那么里面就有一个子集,包含人类社会/市场,其实市场经济也是一种敏捷的状态。比如在中国,改革开放实行市场经济之前,都是计划经济,其实是一成不变,按部就班,比较僵化的。而市场经济则是完全调动了所有人的能动性,但是因为巨大的信息量的冲击以及不确定性的提高,也让大家又忙又乱。我们回想一下改革开放总设计师邓小平说过的一些话,也体现了敏捷的概念,比如“不管白猫黑猫,能捉到老鼠就是好猫”、“摸着石头过河”等等,所有事情都是第一次的时候,只能先试验、再总结经验、最后推广开来,这些都是敏捷思想的体现。接下来还有一个子集,包含了公司/企事业单位等,它们要在市场中生存竞争和发展,其实也很符合自然规律。那么更为细分,在公司里再分出一个子集,这就是敏捷开发交付的一个重点,比如产品项目。这四种不同的形态,层层嵌套,从宏观的现象说明我们为什么要敏捷,或者说是敏捷要解决的是什么问题呢,这里就引出一个理论基础,叫做:复杂自适应系统。比如说大自然、天气、环境污染,甚至说世界政治经济环境都符合复杂自适应系统的特征,关于这些特征,军事界有一个概念叫:VUCA,是指面对的情形将处于”不稳定”(Volatile)、”不确定”(Uncertain)、"复杂"(Complex)、和"模糊"(Ambiguous)状态之中。对这个系统有兴趣的话推荐阅读凯文·凯利的《失控:机器、社会与经济的新生物学》,以及纳西姆的《反脆弱》,这两本书对复杂自适应系统都有很好的阐释。

再说回软件产品研发,我们可以从一些其他的角度来看待复杂自适应性。先举个其他例子,比如说航海,我也算是乔布斯的粉丝,他曾经在采访里说过,在这个技术高速发展的时代里领导苹果公司在复杂多变的市场里前进,就像是杰克船长带领船员在海上找到下一个目的地。联系到软件产品研发,那么就有两个维度,一个是 What,就是我们要实现什么,要达到什么目标。另一个是 How,就是说我们怎么去实现这个目标,怎么去做的问题。这两个维度都有一定的复杂性和不确定性。

好比我们一起乘一艘船出海,并且给远处立一个十环的箭靶,那么我们想快速找到这个靶子并打中十环,这个目标就是 What。理想状况下我们想走一条直线到箭靶前并且打中十环,但是海面上的不确定因素太多,比如来一个侧风,我们就只能走“之”字形,或者遇到大的风浪只能换路线前进。这个箭靶其实就是客户的真实需求,我们想打造一个能获得客户的青睐,为他们创造价值的产品方案,但是箭靶的位置其实一开始是非常模糊的,甚至是在移动的,至少没办法在前期就把握百分百正确的一个方向。还有一个不确定性在于就算明确知道需要做的产品形态,比如箭靶的位置,但是这个范围可能很大,很难定位可以真正为客户创造价值的十环在靶子上哪个具体位置。除开市场和客户需求等外部的不确定性,还有内部比如技术、合作、时间、投入等等的不确定性,所以说一开始定一条直线是没有意义的。为了向前行进,敏捷的方式就是我们可以先在近处设一个小目标,这样就能更容易地看到当前的十环,这样可以让我们与大目标间的路线越来越清晰,达到最终目标上的十环。

接下来讲讲怎样定义“敏捷”,这是一个很有意思的话题,因为我们在与各种客户、同学沟通过程中,每个人对“敏捷”的理解都很不一样,比如一些领导认为敏捷等于快;一些开发工程师觉得敏捷就不需要写文档,觉得非常好;一些喜欢做流程改善的公司会说敏捷看起来比较适合小团队,不适合他们这种大型公司,当然我也认可敏捷是“小强”的观点,但是小强也是适者生存的一个典范,而且大象也可以跳舞嘛;还有一些经理们可能认为敏捷也就是一套典型的方法论,用来代替传统的方法,这是团队的事,与经理个人关系不大,团队参加几天敏捷培训就能自动敏捷起来;也有一些同学认为敏捷等于 Scrum,一看没在用 Scrum 就觉得肯定不是敏捷。这么多的不同理解,让我说的话,敏捷就是要一统江湖。其实我们可以从下面三个视角来理解敏捷:

首先就是要保持一个学习者心态,老乔的“Stay hungry;Stay foolish”,用积极的心态去打造调整能力,创造最大的价值。从研发产品的角度说,就是以客户为中心,打造适应、调整整个组织的能力。从管理或者交付来说,敏捷确实是在复杂多变的情况中一种快速反馈循环的产品研发交付方法,通过完成每一个小目标一步步迭代、持续反馈调整优化从而达到最终目标。敏捷背后的科学原理就是试验性过程理论的三根支柱:透明、检视、适应调整,然后形成一个快速反馈的循环,通过一系列小的循环快速向前推进。当然如果在推进的过程中发现没有办法达到预期,也需要及时止损,去进行其他的“航行”。那么通过这样一系列的往前推进,希望达至的状态有五种,我们称为“5 个持续”,第一个叫持续交付,通过每次完成一个小目标往前推进,交付任务的价值(Value);第二个叫持续优化,因为你和你的竞争对手都面对着多种的不确定性,其实是在看谁能更快获得新的、正确的认知(Knowledge),比如客户真正的需求是什么、更合适的架构是什么等等;接下来就是持续改进我们做事情的方法(How),比如怎么去沟通,怎样做用户故事,怎么做风险管理、工作量评估,导入怎样的框架等等,这些都是具体的一招一式的方法;之后就是持续提升能力(Competence),因为方法和能力是两个事情,比如你和师傅学厨艺,都是同一把刀,工具(方法)都是一模一样,你和师傅切出来的不一样呢,因为你们的功力(能力)不一样;最后是持续塑造文化(Culture),比如说到团队这个层面,就是指团队的价值观、氛围、能动性,以及团队所在的组织对其的支持等等。以上 5 个持续就是敏捷想达到的一种境界。

接下来我们看几张图,红色线条指敏捷方法,黑色线条是传统方法,为了方便理解,我们用身边的例子,比如回转寿司和普通点菜吃饭的体验对比来说明一下。比如可见性,回转寿司与普通的根据菜单来点菜不同,菜单可能有欺诈性,而回转寿司就像是一个持续可见的可视流,所见即所得。适应性就是说这道寿司不好吃,那我就马上换一盘做调整,那么继续吃继续调整的话总会得到更好的用户体验。而说到业务价值,回转寿司的话你会先拿最想吃的那盘,那么在最短时间就可以获得最高的业务价值。关于风险,比如说我不知道这家回转寿司的口味,那么我坐下来吃两盘觉得味道不对,那我就可以及时止损买单走人,但是在普通的餐厅吃饭,点了九菜一汤,结果第一口就觉得太辣了吃不习惯,退菜重做也不行。刚刚是从用户的角度来说,那么从业主及厨子(开发人员)角度说,他是能直观看到顾客喜爱吃哪种,及时对菜品的增减作出调整,和用户共创一个良好的体验。

接下来讲一讲“敏捷的全貌”,首先敏捷是一个很大的概念,而不是一套单一的具体方法,流程或者框架。比如用以一棵大树举例,那么对它来说最重要的是树根,树根扎根于土壤中,在敏捷这个大概念里,土壤可以理解为组织或者项目内的价值观,支撑它笔直向上生长的树干就是“原则”,这棵树逐渐枝繁叶茂,它的枝叶就相当于敏捷概念里的“招式”。这和我们中国的一些传统文化也有相通之处,比如说江湖这个概念,那么江湖里就有武功,里面还会细分一些流派,比如武当少林丐帮等等。而在敏捷流派里,Scrum 就好比丐帮。Scrum这个词来源于橄榄球,橄榄球的球队大家也知道,就是人多势众、乱中取胜,在混乱局面中集中所有能量及时响应互相配合,尽快触地得分。还有一些比较常见的流派比如极限编程(XP)、DevOps、精益看板等等,也有一些小的流派,树枝树叶总体来说是保持一个持续发展的趋势。除了单一团队,我们还有 LeSS 这样的框架,是适用于大公司的规模化敏捷,还有像 MVP、设计思考(Design Thinking)这些概念,它们背后一定是符合敏捷原则的。从另一方面看,假设这棵树是一个团队、一个产品,如果这棵树长得特别茂盛,成果特别丰硕,那么一定也是有外部环境的影响比如阳光雨露的滋养,一定有组织土壤上的支持,我们叫“生态化敏捷”,它一定是形成了一个良性的敏捷生态。

这里的敏捷宣言就是一个总结,可能一些同学和软件研发领域不直接相关,那么把“工作的软件”替换为“工作成果”也是共通的。从敏捷宣言可以看出左边蓝色的描述即为我们需要关注的核心,是价值观的体现,而右边部分是被“高于”而不是被“排除”,做好右侧事项可以给我们左侧的目标提供更好的支持,右边需要持续改进

同时也给大家分享敏捷开发的十二条原则,对照这张可视化表为大家快速讲解一下:

  1. 即创造客户价值;
  2. 是因为我们面对各种变化和不确定性,所以我们要有拥抱变化的能力和意愿;
  3. 是需要去持续交付;
  4. 是所有人要在一起工作来实现共创;
  5. 意思是信任和支持我们的团队,带来更多的尊重和理解,而不是一味要求对方 996;
  6. 是指面对面的频繁沟通;
  7. 是指可工作的软件或成果才是度量工作进展的最好方式,而不是只描述这个产品的设计文档或者 PPT;
  8. 是指工作中保持一个良好的发展节奏,而不是猛冲几次然后后继乏力,如果没有一个空间让团队进行反思并且提升能力、优化方法,只会让团队原地踏步;
  9. 是说要持续关注技术的卓越性才能带来敏捷,这条非常重要。做过开发的同学可能深有体会,要时刻锻炼自己的“招式”,提升专业程度和职业操守,保持技术的前沿性,守住能力、品质的底线,不做一些半成品;
  10. 是指简洁为本,敏捷的理念就是开始设置一些小目标,然后聚焦所有的能量去击中这个小目标,通过这个小目标去往下发展。所以怎么去应对复杂,就是通过一系列简单的目标的实现去叠加复杂性;
  11. 即自组织文化;
  12. 则是持续的反思与改进。

在最后的“成功与成长”章节,我来做一个总结。如果大家读过 Scrum 指南应该就会知道一个高效的 Scrum 团队会有 5 个团队价值观:勇气、开放、专注、投入、尊重。成功和成长都有赖于这五个价值观形成的文化。以划龙舟为例,如果用 Scrum 作为敏捷的基础框架来进行导入,那么一般会有三个角色:划船、掌舵和打鼓的,这三个角色三位一体在一条船上一起共创,在充满不确定因素的波涛中向前推进。

如果带入 Scrum 框架中,那么三个角色分别是 PO(Product Owner 产品负责人),相当于掌握方向的舵手,划船的人就相当于 DT(Dev Team),打鼓的则是 Scrum Master,通用一点的话可以称这个角色为 Coach。那么 PO 就是呼应了前文所提到的“What”,我们要交付正确的产品,实现正确的价值;DT 则是对应“How”,需要团队持续且正确的交付;那么 SM 则是负责“Why”敏捷,给 PO 和 DT 赋能,使他们能做得更好,达到之前所说的“5 个持续”的状态;最后实现与客户共创,最重要的两种客户可以分为产品的使用者,与确定购买的决策者。有很多同学也提到项目管理里还存在利益干系人。其实干系人越少越好,以防出现这个角色不太懂敏捷,没有与团队达成共识的情况下变成利益干扰人,一字之差就增加了项目管理的复杂性,这样就只能移除这种障碍,以便让龙舟队能直接触达客户。这才是我们要打造的良好的组织环境。

最后总结一下,本次课程提到了一些概念以及很多关键数字,有复杂自适应系统的 4 个特征;在产品研发追逐移动靶的过程中需要关注的复杂自适应的两个维度;也有敏捷背后的科学原理-试验性过程理论的 3 根支柱;还有 12 条敏捷开发原则等等,最重要的是在实践过程中融会贯通,以达到真正的敏捷

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-04-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾云 CODING 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档