【专题文章】敏捷开发方式的火爆正是因为大家发现传统的瀑布方式无法适应企业在变革和创新驱动下的动态管理。如何在项目开发中不断满足不断变化的用户需求，越来越受到开发者和管理者的关注。敏捷开发已成为许多团队的制胜法宝。接下来，我们采访了来自北京寻思微科技有限公司的资深敏捷教练袁斌先生，与网友们分享敏捷在项目实践中的一些心得体会。袁斌，工学硕士，MBA，Scrum、AUP、敏捷建模、XP、看板等资深实践者，资深敏捷教练。在过去的20年里，他曾在从事软件和产品开发的全球公司工作。曾担任Anoto产品和Mino产品中国区软件开发总监，使用Agile&Lean实现产品快速交付，响应不断变化的需求。在8年多的敏捷开发&精益开发实践中，在电信行业、外包团队、互联网产品等行业积累了丰富的经验。以下为采访视频实录：记者：大家好，今天我们的嘉宾是北京寻思微科技有限公司资深敏捷教练袁斌先生，为我们讲解敏捷实践中的一些主要问题开发项目，分享对未来几年敏捷开发的一些看法。首先请袁总给各位网友介绍一下自己。袁斌：大家好。我是袁斌，来自Synswell。我有八年多的敏捷实践经验，所以我把自己定位为资深的敏捷实践者。好的谢谢。记者：嗯，在敏捷里面，很多人都看到了它的成本控制，可以减少项目开发中的一些浪费。但往往适得其反，非但没有减少，反而增加了开发成本。在开发成本控制方面，您是如何理解的？袁斌：其实从成本上来说，每一个新的方法都要有它的学习曲线和学习成本。往往在开始的时候，它的结果会比现有的情况更糟，呈U型曲线。所以更多的是关于如何降低你的学习成本和学习曲线。如果在初次使用敏捷时采用整套敏捷开发实践，高昂的学习成本和学习曲线会大大降低实施敏捷的效果。所以我这里的建议是，对于成本的控制，首先找到你在研发过程中最大的痛点，基于痛点，然后在敏捷开发的众多实践中，找到一套针对这个痛点的实践。这套实践合集的原则是学习成本要低，并且可以持续改进，最适合你的痛点。这样，持续的改进和持续的成本控制才能获得满意的投资回报。记者：在敏捷实践过程中，有没有使用过一些敏捷工具，能推荐一些更好的工具吗？袁斌：敏捷工具是这样考虑的：看你的产品周期。如果你的产品周期比较短，比如两三个月，那么我个人不建议使用敏捷工具来考虑和管理你的敏捷开发。过程。如果周期比较长，我推荐使用敏捷管理工具。因为主要是，第一，你要积累很多数据，这有助于分析你的过程，哪些是好的？哪些不好？，然后进行有针对性的改进；第二，对于整体的需求管理，包括对你的一些技术方案的管理，你需要一个工具来进行整体的管理。记者：在项目中，敏捷测试人员的职责和技能要求是什么？袁斌：我觉得在敏捷开发过程中，测试人员可以更多地帮助团队，帮助团队对最终的交付有保障。因此，敏捷测试人员首先应该尽可能早地进行测试，并且更早地进入测试周期。例如，在迭代开始时，他可以介入计划会议。他从用户层面给出了很多对需求的看法，可以帮助团队更好的理解需求。同时，通过把握测试的风险，尽早为研发团队提供“bug发生风险高”和“用户使用频率高”两个层面的用例，帮助团队把控研发过程中的风险。我觉得继续测试也是很重要的，能够帮助到团队，尤其是研发团队，不仅我可以尽早的进行这些测试，而且还要继续进行这些测试，及时反馈风险给研发团队。记者：据我了解，很多朋友都说你们在测试这方面，好像不需要专门的测试人员似的。你觉得这样的公司对一个项目的发展有什么影响吗？袁斌：有些公司，比如Facebook，会说我没有专职测试人员，这是一种工程师文化。但是我个人认为在我看到的很多项目中，测试人员是必不可少的。我来说说我的观点。我觉得如果没有测试人员，对工程师的要求是很高的，因为他要背负专业测试人员的技能。记者：对于他的一些个人技能，要求会很高。袁斌：对，我觉得科技行业有专攻。测试人员更多的是从用户的场景来测试产品，尤其是非功能需求的测试。这方面的专业技能要求也很高。记者：要实现敏捷开发，每个团队都要经历一个过渡期。在过渡期，各支球队需要根据自身的差异，找到合理有效的解决方案。你通常如何处理这个问题？袁斌：在团队转型的时候，我们看到很多团队，包括我们自己的客户，最大的问题就是敏捷开发的实践很多。如果所有的做法都被采纳。然后在团队中全部使用它们，但每次实践都有学习成本。所以把他们都拿过来之后，团队很抗拒，解决不了团队的实际问题。因为练多了，大家都觉得很累，有时候适得其反。我个人的建议是，在过渡期，使用痛点驱动的方式。所谓痛点驱动，就是找到团队目前比较严重的痛点，在敏捷实践中找一些实践合集，不是全部，而是找一些实践合集来解决痛点。然后在看下一次迭代的时候，继续找到目前最大的痛点，然后用一些练习集去解决。当你一直这样做时，团队阻力就会很小。他觉得可以，我的实际问题也解决了，他会很愿意采用敏捷。记者：您刚才说痛点驱动，能解释一下吗？袁斌：所谓痛点驱动，痛点其实是最大的问题，也是我在研发过程中遇到的最大的问题。例如，我可能正处于这个过程的中间，我最大的问题是迭代交付延迟。记者：推迟？袁斌：对，我推迟了，可能最大的问题是对需求的理解不够，或者最大的问题是人员流动。那么比如说，人员流动是个大问题。这时候在敏捷实践中，不一定要用测试驱动开发，而是用用户故事来描述需求。可能是结对编程，或者团队的代码责任会更有效。还可以强调整个团队都应该参与计划会议的讨论，以减少学习债务。这些做法可能对你目前的痛点更有帮助。建议首先采用这些做法。这是我的观点。记者：在敏捷过程中，我觉得最重要的是一个需求，一个分工，一个分工。能谈谈如何合理拆分需求和分工吗？袁斌：我的观点是，如果是需求，尽量采用pull的方式。所谓pull方式，就是我们的研发流程是从需求分析到设计、编码、测试，再交付给客户。我的观点是，我们应该从客户端开始。客户端想他最需要什么需求，然后把这些需求拆分的更细。所以在Scrum中，它有一个产品待办列表，它被翻译成需求列表。这个需求列表中高优先级的一定是客户最想要的，所以我建议把高优先级的需求拆分出来，对用户最有价值的需求会更好。记者：在敏捷开发过程中，Scrum和XP，也就是我们所说的线性规划，据我了解在国内，使用Scrum的占大多数。袁斌：对。记者：能否介绍一下Scrum与其他几种方法最大的区别？如果是Scrum，它的优势是什么？袁斌：其实Scrum的主要特点是它是一个轻量级的框架，通过短周期迭代交付最有价值的产品，能够从容应对不断变化的需求。我觉得它最大的优势就是没有介绍很多实现细节，具体是如何交付一个有价值的东西，不想洗介绍。我认为这可能是它最大的缺点，但也是它最大的优点。它可以容纳许多其他方法，例如极限编程(XP)。它可以在XP中集成许多工程实践，以帮助其提高交付质量，并且可以适应精益软件开发并消除研发过程中的浪费。所以Scrum，我认为它最大的优势，是一个轻量级的框架，很容易适应。从另一个方面来说，它在中国可以很受欢迎，因为它是一种管理方式。事实上，Scrum偏向于敏捷项目管理，项目管理在国内很容易被认可。所以我觉得在国内可以更好的推广，这两点比较重要。记者：极限编程更注重细节，可以这么说吗？袁斌：极限编程对工程实践很有指导意义，但是对工程师本身的要求比较高。Scrum对工程师的要求相对较低。记者：也就是说，一般来说，我们国家的一些创业型公司的项目是可以使用Scrum的。袁斌：总体来说是可行的。同时，Scrum不仅应用于软件产品的开发，还应用于许多其他行业。记者：是不是说不局限于软件开发行业？袁斌：对对对。记者：所以如果能够得到准确的数据支持，敏捷实施才能发展得更好。敏捷实践下如何衡量员工和程序员的工作指标？袁斌：我明白你的意思。在我们的实践中，我们将程序员的工作指标分为两部分。一方面是团队。首先，我们不关心每个人的工作量。我们要关心团队的每一次交付。是否可以？接受？这样大家就会有团队观念和整体观念。另一方面，我们需要关注个人。当我们关心个人时，我们通常关注四个层面。首先是工作质量；二是工作量；三是主动性，因为在敏捷开发中，短周期Iteration需要非常高的风险控制，需要有很强的主动沟通意愿，有助于将风险前移；第四个我们认为是帮助，就是帮助球队。记者：敏捷团队在工作的时候，有时候他们的项目过程会暴露出来，也就是我们常说的项目透明化。这是一个可以称为敏捷开发过程的错误，还是您对项目透明度的看法？袁斌：首先，在敏捷开发中，项目透明度要求很高。在我们的实践中，我们会发现，如果你把这个项目透明化，你会减少很多沟通成本和障碍。现在我们可以看到项目透明的方式更多的是白板。无论是物理白板还是电子白板，我们都把这个项目放在一个透明的环境中。很多团队会做一个项目墙和任务墙，把所有的状态都安排在墙上。另一种方式是电子白板，它有很多工具。这两种方法可以暴露您的项目风险。项目透明后，有兴趣的项目利益相关者会来帮助我们的团队，发现项目的潜在风险，并帮助您解决。记者：是的，Scrum会议中的实践实际上是实践控制中最重要的事件。袁斌：对。记者：这是球队提升的最好时机。您认为Scrum会议在团队中是如何建立的？在Scrum中，它有一个回顾会议是非常重要的。这是如何运作的？袁斌：回顾会议其实在Scrum中起到了持续改进的作用，而敏捷非常强调持续改进。回顾会议是持续改进Scrum的绝佳机会。但现在可以看到的是，回顾会议对于团队来说往往是走个形式，没必要开。更多的情况，我认为是回顾会议在这个时候没有发挥应有的作用。我觉得还是开个回顾会比较好。首先，它是数据驱动的。所谓数据驱动，就是我们用数据找出本次迭代最大的问题是什么。找到问题后，团队分析其根本原因，然后找到解决方案。然后取两个或三个好的解决方案，并在下一次迭代中巩固它们。回顾会议的核心是发现根本问题，所以我个人比较推荐使用数据。例如Bug分类、计划与实际偏差。例如，如果您每天工作八小时，那么您可以有效地工作三个小时。我们可以分析一下另外五个小时都浪费在哪里了？这几点会暴露问题。记者：在Scrum会议中，除了回顾会议，还有其他的会议吗？袁斌：Scrum？记者：是的，在Scrum中。袁斌：Scrum其实有几个重要的会议。首先是它的计划会议。在迭代的开始。计划会如何在迭代过程中确保承诺的东西能够高质量交付。第二个推荐的课程是每天早上15分钟的站立。这个站立会议可以和我们前面提到的白板一起使用，使项目透明化。如果你想开一个好的站立会议，最好是所有成员都在白板前举行。这时候，每个成员都会在白板上公开自己的工作状态和风险。另一个会议是审查会议。当迭代即将结束时，我们将看本次迭代的交付是否能够满足迭代的初始目标。然后是回顾会议。回顾会议是我们最不需要看到的事情，看看哪里做的不好？哪个做得好？下一阶段如何改进。记者：目前国内有很多敏捷教练。你是一名资深的敏捷教练。您认为敏捷教练在团队中的主要工作是什么？敏捷大师在Scrum工作中建立了角色转换。袁斌：我觉得是这样的。教练在一个团队中。对他来说最重要的是随时帮助团队实施敏捷，包括敏捷思维和敏捷实践，使其落地。更详细的说，可以通过敏捷的思考和实践帮助团队解决团队存在的问题，这也是我的实际实践。也就是说，敏捷教练与团队合作，通过一些敏捷实践，包括其他开发模式的优秀开发实践，帮助团队解决问题。这个时候我觉得一个敏捷教练最应该做的事情。记者：在项目中，是一个不断完善的过程。不能说一步一步来，敏捷就是要求他们这样做。袁斌：对，因为很多敏捷实践背后都有假设。它假定团队成员的技能水平以及公司文化如何支持尊重和平等。但是，如果项目中不存在这样的假设，如果我们把这些做法照抄过来，肯定会出现很多冲突。记者：未来几年敏捷开发的发展，您希望看到哪些方向？袁斌：我觉得未来几年，我希望敏捷能够落地，真正帮助团队解决实际问题，提高质量，提高效率，增加交付的商业价值。这是我希望看到的。二是说我非常希望大家忽略敏捷这个词。不再是我用敏捷，或者说我不用敏捷，而是我们用敏捷实践和它的思想，甚至说我们是基于它的思想，基于我们团队的现状，做出一些为我们自己的企业和团队定制一套方法。然后我把它放在地上，给团队带来了实际的好处。我们不再谈论它是否敏捷，而是实际不断改进。记者：好了，今天的采访到此结束。今天非常感谢袁斌老师给网友们分享了项目实践中敏捷开发过程中的一些主要问题。谢谢袁斌老师。袁斌：谢谢老师，还有这个平台。
