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