课程不仅为学员韩陈昊提供了全方位了解组织中敏捷实践和经验的机会,更深入剖析了敏捷转型的成功路径。CSP-SM课程是提升团队敏捷能力的有效途径。学员韩陈昊通过共创环节积极协作,碰撞思想,为获取知识和灵感提供了独特的学习体验。
最近国内传统企业正积极进行数字化转型,特别是敏捷成为备受瞩目的焦点。我常常被非IT领域的朋友问及敏捷的真正含义。随着敏捷概念的普及,不同领域的人对敏捷有各种定义,导致出现了许多自称敏捷专家、学者和从业者,形成多样的流派。相较于我早年熟悉的软件工程实践,如今对敏捷的讨论有了显著变化。
观察发现,多数从业者倾向于基于个人特点对敏捷进行定义。例如,人力资源部可能将教练技术视为敏捷,因为这种对话方式能与其原有技能衔接;产品部有时将使用“用户故事地图”看作敏捷,因为在当前产品理念下,画原型并非“高级”;运维出身者可能将DevOps看作敏捷,研发团队中有人将“微服务”和“领域驱动设计”看作敏捷,甚至爱好绘画的人将制作视觉笔记视为敏捷。
有引导能力者将组织活动视为敏捷,经验丰富的管理者可能将构建“中台”看作敏捷。因此,敏捷以大家最熟悉的形式逐渐成为数字化背景下谋生的技能。我报名参加CSP课程是因为我早在年初就制定了学习计划,担心随着年龄和管理职责增加,可能会失去对实际业务的理解和复杂场景的实践能力。
CSP课程集结了来自不同背景和行业的同学,为我提供了全方位了解组织中敏捷实践和经验的机会。在课程中,我听取了他人在工作中实施敏捷的经验,观摩了他们在实际工作情境中练习的技能,并通过共创环节与其他学习者积极协作,碰撞想法,这为我获取知识和灵感提供了有效途径。
在这次课程中,我们全面学习了教练能力和团队评估的技巧,包括培训、演讲、引导、领导力、组织设计、敏捷转型路径设计等多个方面。整个课程过程中,一个困扰着我们的问题一直是:什么样的敏捷转型才算成功?然而,课程结束时,我突然发现这个答案早已写在了敏捷宣言中。
我们首先将敏捷定义局限在软件开发领域,随后发现其中最关键的四个方面分别对应四类角色:业务/产品、研发/运维、商务/运营、执行/管理。
要评估敏捷转型的成功程度,无需设计过于复杂的度量标准,直接找几个人对照敏捷宣言进行比较即可。强调个体和互动高于流程和工具,鼓励加强跨团队沟通和提升个体能力。这优于各部门孤立工作,不可取的是试图将团队成员当成流水线工具。
以“用户故事”为例,原本是促进研发、产品和业务沟通的工具,但在陷入敏捷泥潭的团队中,有人认为用户故事不够“完美”,导致沟通僵局。因此,突破部门和业务之间的矛盾,相互了解对方的难处,共同致力于提高产品能力,比具体的流程和工具更为关键。
强调工作的软件高于详尽的文档,突出结果至关重要。在市场经济的推动下,软件公司衡量项目成功的标准是能否以最少的成本、最快的速度交付优质软件。在这样的环境下,提高工程实践能力、减少不必要浪费成为唯一选择。
工程师们需要思考如何利用自动化手段提高团队效率,通过刻意练习提升编程技艺,以确保在没有增量和经济下行的时候仍能生存。客户合作高于合同谈判,强调软件从业者要意识到所处行业是一个服务行业,而不是创新的知识分子。
合作的基础在于站在客户角度思考,尊重理解客户需求。外包公司的未来发展方向是对外租赁专业能力,按需按时按量付费。只有通过充分理解客户,形成合作基础,才能实现共赢。响应变化高于遵循计划,是敏捷转型的前提。拥抱变化意味着不受固定的框框限制。企业转型不顺利的原因大多是过度追求工作的确定性,导致僵化无法适应变化。
中层管理通常遵循计划以缓解焦虑,但这种行为并不能带来预期的结果。在快速变化、复杂性增加的世界中,响应变化有助于发现问题根本原因,看到多种可能性,更好地管理和适应挑战,抓住新的机会。
本次课程一开始,两位老师进行了一场精彩的闪电演讲,各地学员分享了他们对管理团队的感悟。每位学员演讲结束后,导师从结构、内容价值和台风三个方面进行了自评和互评,取得了良好效果。成功的演讲需要明确传递信息和表达观点,同时要考虑时间、听众和环境等因素。
为克服紧张情绪,演讲者需要充分准备和预演,确保内容结构清晰,利用可视化手段更好地表达。接下来,我们深入学习了敏捷教练的能力模型,学员们可以根据相对标准评估自己或所在团队的能力。这个能力模型就像一面镜子,帮助每个人认识到自身的不足之处,并制定提升计划。