现在有许多提高软件开发的方法,敏捷和精益是其中盛行的两个。管理者必须决定在其组织机构中运用哪种方法,也可以依据需要解决的问题,来考虑结合运用多种方法。
在题为敏捷地构建,精益地学习的演讲中,Régis Medina 分享了从两种方法中学到的知识。针对敏捷与精益相结合这一话题,InfoQ 对Régis 进行了采访,采访的话题重点聚焦于人与学习两方面。
InfoQ:在 2013 年的中欧精益和看板大会(LKCE13)上,你为我们带来了题为“敏捷地构建、精益地学习”的演讲。为什么推荐这样一种组合?
Régis:在敏捷宣言问世十年之后,敏捷已经证明了自己在以下方面的有效性:减短开发周期、显著提升质量、消除团队内部的孤岛,以及让项目管理变得更容易。然而,当我考虑敏捷团队在实际工作中所面对的问题时,我发现了正在浮现的三项新挑战:
- 制造正确的产品:这需要改进产品所有者的实践。我看到太多的产品所有者在迭代之间改变行动方针,或是要求获得一些最终不会得以使用的特性。这一挑战正是在收集用户的需求之上,发展产品所有者的技能,从而能够只开发必要的特性。
- 在每次迭代结束时交付更多。在太多情况下,交付特性的数量令客户感到失望,因为客户有着自己需要满足的截止时间——不论与开发团队进行了怎样的协商。在这种情况下,敏捷团队往往毫无头绪,因为他们不知道如何加快开发速度,同时又能够保证其软件质量,而且还不需要加班。
- 学习如何与其他部门更好地协作:公司内部的其他部门——敏捷团队身处的价值流中的上下游环节。在我刚刚提到的情景中,市场团队要求更快地交付更多的特性。价值流的另一端,随着 DevOps 的兴起,美好的前景正在浮现。但是具体来说,要想让价值流的其他环节跟上自己前进脚步,敏捷团队将经历一段艰难的时光——因为这往往会造成产品的延迟,或是引发意外事件。在这一领域中,我所见到的主要阻碍之一,是敏捷团队难以与他们自己的管理互动。
面对这些主题,敏捷社区正在持续不断地进行探索,并尝试新的理念。从我个人的角度来说,在进行敏捷实践十年之久后,我决定后退一步,把握住接受真正的精益导师的指导,从其他 IT 领域中学习精益的机会。当看到多种领域里精彩纷呈的成绩时,我意识到对敏捷社区来说这里存在着巨大的机遇。
精益与敏捷能够完美契合,但是在本质上来说却又截然不同。精益并不是一套流程,或是一套用于改进流程的工具箱,而是一种管理实践——在导师的帮助下,许多人经过若干年中演化得来。进行精益实践的管理者和团队领导者,实际上是在学习:
- 如何提升客户满意度,甚至超越其最初的要求。
- 如何识别其团队中的改进机会,以获得显著的、可衡量的绩效提升,并将其与公司需求联系在一起。他们通过让事情在第一次就正确地完成、改进众人之间的工作流,或是找出更快速完成特定任务的方法,来实现这一目标。
- 如何创造这样的工作环境:团队成员置身其中,能够更快地发展正确的技能,并更深入地思考如何更好地完成他们的工作。
InfoQ:敏捷和精益的结合如何帮助我们,增进在能够交付给客户的价值方面的洞察?
Régis:由于其迭代特性,敏捷能够让客户——或者至少是一个客户代表——大量参与项目。但是当我们从客户的角度理解价值的时候,还是能够发现改进的空间。这并不容易,因为客户提出的要求,并不一定是其真正需要的,或者不一定是之后驱动其做出购买的因素。
而这正是精益派上用场的时机:
- 它培养了一种“去现场并查看”(Go&See)的习惯。用精益的话来说,这叫做“现场确认”,它意味着深入实地工作以了解客户身处的环境,并明确客户试着解决的问题。
- 它提供了一套框架,用于分析客户期望、理解客户使用产品或服务的方法。精益培养我们的能力,以在实地工作中发现价值和浪费。这将有助于理解客户的体验并改进产品,从而在创建中尽可能少地做无用功。
- 它有助于让团队成员与这些目标相匹配,更多地聚焦于需要为客户解决的问题,而不仅仅局限在列表中的有待开发的特性。
- 它让我们能够将产品演进视作一系列持续不断的实验,从而有助于更好地理解客户环境和倾向。
InfoQ:敏捷和精益都有助于我们关注人的因素。能否解释一下,它们是如何互相结合的?
Régis:敏捷强化了项目利益干系人之间的协作与沟通,并创造了有利的环境,来帮助团队以可接受的节奏更好地完成工作。这与精益中的“尊重人的因素”非常接近。但是精益凭借训练的理念,在这方面走得更远。
Taiichi Ohno 认为,我们每天在组织机构中见到的浪费,都是我们错误想法的结果。在精益中,对技能发展以及提升每个人的判断能力方面所付出的投入,是取得成功的关键因素。精益中的主要问题是:“对于什么使公司成功这个方面,谁需要进行学习?”。
确实,精益是一系列实践和练习,其目的在于培养人们的能力:
- 基于 PDCA(计划 - 执行 - 检查 - 行动)循环的解决问题的方法,有助于帮助我们理清思路,从而:首先选择正确的难题;其次,基于事实而不是信念做出决策。
- 丰田生产系统中的两大支柱——恰到好处(JIT)与自动化——定义人们用来提升自身其技能,而需要持续解决的问题的标准类型:以正确的节奏并肩工作,并且在第一次就把事情做好。
- 写下标准,并在工作中持续履行,有助于加速技能成长并传播实际知识。建议在团队层面甚至整个公司里进行实践。
这些实践都完美地适用于敏捷世界。
InfoQ:组织机构是否应该首先以敏捷入手,随后再采用精益;或是以相反的方式?又或者,是否有什么方法能够混合二者,以便组织机构同时采用它们?
Régis:对于这个问题,精益的答案实际上是另一个问题。由于敏捷是一系列开发实践,我们可以把它作为一种解决方案。所以,这个精益的问题是:对于你所面对的问题,哪些可使用敏捷作为解决方案?如果并不存在问题,却要强加一套解决方案,那么会导致时间的浪费、引入更多的问题(比解决的更多),或者反而留下真正的问题未能从触及。
从这个逻辑来说,我鼓励管理者提出这些问题,以便:
- 清晰地定义需要解决的问题,并理清原因,说明为何这些问题对公司非常重要。
- 让全部团队成员面对挑战。
- 与团队成员一起,识别出实际工作中横亘在他们的道路上,阻挡他们获得成功的主要障碍。
- 领导实验,帮助团队成员克服这些明确的障碍。
- 在团队内部,甚至在团队之上的整个组织机构层面,传播和分享诀窍。
……这意味着已经开始采用精益了!
InfoQ:你还提到了精益地学习。那么敏捷回顾呢?它们也能够帮助团队反思和学习。
Régis:是的,敏捷回顾为我们带来了学习的完美机遇,即使其结果趋向于千差万别——取决于领导团队的教练所拥有的技能。对我来说,如果希望找出下述问题的答案,那么回顾是有效且有用的:
- 团队如何知道自己正在面对正确的问题,并且正在学习需要学习的东西,而不仅仅是它想要学的?
- 这种学习,如何提升团队中每个人和每个成员的技能?
- 如何评价这种学习为客户和公司带来的益处?
话虽如此,回顾更多地是一系列用来进行改进的方法,在每个迭代中都会出现一次,并且处理(希望如此)限定数量的问题。精益则帮助形成日常的持续改进,一个问题接一个问题,以确保每个人、每一天都能够对提升和改进做出贡献。它基于不同的方法进行可视化管理——Obeya 大屋模型——其目标在于让问题显现,驱动团队持续协作,从而解决这些问题。我认为,这是一种“持续的回顾”。
读者也可以在 2013 精益 IT 峰会网站观看这次演讲的视频: Lean & Agile by Régis Medina 。
评论