袁斌：敏捷开发在项目中的解决方案

袁斌，工学硕士、MBA， Scrum、AUP、Agile modeling、XP、kanban等资深实践者，资深敏捷教练。近20年中就职于全球性公司从事软件和产品的开发。曾任Anoto产品和Mino产品中国区软件开发总监，利用Agile & Lean实现产品快速交付，应对变化的需求。超过8年敏捷开发&精益开发的实践过程中，在电信行业、外包团队、互联网产品等多个行业积累了丰富的经验。

以下是视频采访文字实录：

记者：51CTO的网友大家好，今天我们请到的嘉宾是北京迅思威尔科技有限公司的资深敏捷教练袁斌老师。跟我们讲解敏捷开发项目实践中一些主要问题，以及对未来几年敏捷发展这一块的一些看法进行分享。首先请袁老师跟网友们做一下自我介绍。

袁斌：大家好，我是袁斌，来自迅思威尔，我自己有超过八年的敏捷的实践经验，所以我对自己的定位是一个资深的敏捷实践者。OK，谢谢。

记者：那么在敏捷当中，很多人都看到了它的成本控制，它能够降低项目开发中的一些浪费。但是往往适得其反，不但没有降低，反而增加了开发成本。在开发成本控制这一块，你怎么去理解？

袁斌：其实对于成本来言，每一种新的方法一定会有它的学习曲线和学习成本，往往在开始的时候，它的结果会比现有的情况还要糟糕，它会有一个U形的曲线。所以这里面更多的是怎么样降低你的学习成本和学习曲线。如果在最开始使用敏捷的时候全盘采用整个敏捷开发实践集合，较高的学习成本和学习曲线会使实施敏捷的效果大打折扣。所以我这里的建议是，对成本控制而言，首先找你在研发过程中间最大的痛点，在痛点的基础上，然后在敏捷开发的众多实践里面去找针对这个痛点的实践集合。这个实践集合的原则就是学习成本要低，而且它能够持续改进，对你的痛点起的效用最好。这样的话，不断地改进，持续控制成本，就可以获得让人满意的投资回报率。

记者：在敏捷实践过程当中，是否使用到一些敏捷工具，能否推荐一些比较好的工具？

袁斌：敏捷工具是这样考量的：看你产品的周期，如果你产品周期相对比较短，比如说你两三个月，那么我个人并不建议用敏捷工具来考量、管理你的敏捷开发的过程。如果是周期比较长的话，我是建议用敏捷管理工具。因为原因主要在于，第一，你要去积累很多数据，这些数据会有利于分析你的过程中间，哪些是好的？哪些是不好的？，然后有针对性的改进；第二，对于整体的需求管理，包括你一些技术方案的管理，需要一个工具能把它整体管理起来。

记者：在项目当中，敏捷测试人员的职责和一些技能的要求是什么样的？

袁斌：我觉得在敏捷的开发过程中间，测试人员更多的是能够帮助团队，帮助团队最后的交付能够有一个保证。所以说敏捷的测试人员首先应该是尽早测试，更早地在测试周期的前面进入。比如说在一个迭代开始的时候，在计划会议他就能够介入，他给出很多从用户层面对需求的看法，能够帮助团队更好的了解需求。同时通过把握测试的风险，尽早的给研发团队“bug出现风险高”以及“用户使用频率高”两个层面的用例，帮助团队控制研发过程中间的风险。

我觉得还有一个很重要的是持续地测试，能够去帮助团队，特别是研发团队，不但是说我能够尽早，而且不断地持续地进行这些测试，及时的把风险反馈给研发团队。

记者：据我了解，很多朋友说你在测试这一块，好像是他们不需要专门的测试人员，你觉得这样的公司对于开发一个项目的时候，有没有什么影响？

袁斌：有一些公司会有，比如说像Facebook，它会说我没有专职的测试人员，它是工程师文化。但我个人认为在我看到的很多项目里面，测试人员是必要的。我说一下我的观点，我觉得如果没有测试人员对工程师的要求非常高，因为他要承担专业测试人员的技能。

记者：对他个人的一些技能，什么要求都会高。

袁斌：对，我觉得术业有专攻，测试人员更多的从用户的场景对产品进行测试，特别在非功能性需求的测试，这方面的专业技能要求也是很高的。

记者：做到敏捷开发，每个团队都要经历一个转型期，在转型期还需要每个团队根据自身的不同找出合理有效的解决方法，一般是如何处理这个问题？

袁斌：团队在做转型的时候，我们看到的很多团队，包括我们自己的客户，最大的问题在于，敏捷开发有很多的实践，如果把所有的实践都拿过来。然后全部用在团队中间，但是每个实践都有学习成本。所以说都拿过来以后，团队很抵触，而且也不能解决团队的实际问题。因为太多了实践以后，大家觉得很疲惫，有时候适得其反。我个人的建议是这样子，在转型期的时候，用痛点驱动的方法。所谓痛点驱动就是，找到团队目前一个很严重的痛点，在敏捷实践中间，找一些实践集合，不要全都找，是找一些实践集合，去把痛点解决掉。然后再看下一个迭代的时候，继续找目前最大的痛点，然后再用一些实践集合把它解决掉。你不断地这样去做的时候，团队抵触很小，他觉得OK，把我的实际问题解决掉了，他会很愿意采纳敏捷。

记者：您刚才说痛点驱动，能否解释一下？

袁斌：所谓痛点驱动，痛点其实就是最大的问题，是我在研发过程中间碰到的最大问题。比如说我可能在这个过程中间，我最大的问题是迭代交付延期。

记者：延期？

袁斌：对，我延期了，也有可能最大的问题是对需求了解很差，或者说人员流动是一个最大的问题。那么比如说人员流动是一个很大的问题，这个时候敏捷实践里面，你不见得非要用测试驱动开发，要用用户故事描述需求，可能是结对编程，可能是团队的代码负责会更有效。也可以强调计划会议里面整个团队都要参加讨论，减少学习债务。这些实践可能是对你当下的痛点会有更大的帮助，建议首先采用这些实践，我的观点是这样的。

记者：敏捷过程当中，我认为最重要的是一个需求、拆分与分工，你能谈谈如何进行它需求合理地拆分，以及分工吗？

袁斌：我的观点是，如果是需求的话，尽量采用一种拉的方式，所谓拉的方式是说，我们研发的流程就是从需求分析、再到设计、编码测试、然后交付客户。我的观点是，我们应该是从客户这一端开始，客户这边认为，他最需要的是哪些需求，然后对这些需求做比较详细地拆分。所以这样在Scrum里面，它有一个叫做Product Backlog，翻译过来叫需求列表。

这个需求列表里面高优先级，一定是客户最想要的，所以需求拆分我建议从高优先级的，对用户价值最大的需求拆分会比较好一点。

记者：在敏捷开发过程当中，Scrum和XP，也就是说我们说的直线编程，在国内据我了解，使用Scrum占了大部分。

袁斌：没错。

记者：你能介绍一下Scrum和其他几件方法最大区别在哪里？如果是Scrum，它的优势在哪里？

袁斌：其实Scrum最主要的特点在于说，它是个轻量级的框架，通过短周期的迭代，交付最有价值的产品，可以从容应对变化的需求。它最大优点我认为是，它没有介绍很多的实现细节，具体要做到怎么样去交付一个很有价值的东西，它没有想洗介绍。我认为这可能是它最大的缺点，也是最大的优点。它可以包容很多其他的方法，比如说像极限编程（XP）。它可以把XP里面很多的工程实践融进来，帮助它提高交付质量，而且它可以包容像精益软件开发，消除研发过程中的浪费。所以Scrum，我认为它最大的优点，是个轻量级的框架，易于包容。而且从另一个方面说，在国内能够很好地流行得益于它是一个管理型的方法。其实Scrum是偏向于敏捷的项目管理，项目管理在国内很容易获得认可。所以我觉得它在国内能推的比较好，这两点是比较重要的。

记者：极限编程比较注重细节方面的一些问题，可以这么说吗？

袁斌：极限编程中的工程实践很有借鉴性，但是对于工程师本身的要求相对比较高。Scrum相对而言对工程师的要求没有那么高。

记者：就是说一般我们国内一些创业型的公司，它的项目都可以用Scrum的方式。

袁斌：一般而言是可行的。同时Scrum不但用在软件产品的开发，还有很多其它的行业都可以用Scrum。

记者：就是说不仅仅限制在软件开发这个行业里面？

袁斌：没错，是这样的。

记者：那么如果能得到准确的数据支持，敏捷实施能够更好地发展下去，敏捷实践下的员工，程序员的工作指标如何衡量？

袁斌：我明白你的意思。我们的实践中间是这样子，把程序员的工作指标分为两个部分，一个部分是团队，我们首先不关心每一个人工作量多大，我们想要关心这个团队的每次交付，是不是可以接受？这样大家会有一个团队的概念，整体的概念。另一个部分，我们需要关注个人，关心个人的时候，一般会关注四个层面，第一个是工作质量；第二个是工作量；第三个是主动性，因为敏捷开发里面，短周期的迭代，对风险地控制要非常高，要求主动沟通的意愿要很强，有助于风险前移；第四个我们认为是帮助，就是帮助团队，

记者：当一个敏捷团队工作时，有时候他的项目流程会暴露出来，也就是我们常说的项目透明化，这是不是可以称为敏捷开发流程的一个过失，或者是说你对于项目透明化有什么见解？

袁斌：首先项目的透明化在敏捷开发里面，他要求的非常高，在我们的实践中间会发现，如果你把这个项目透明了，你会减少很多沟通的成本和障碍，现在我们能看到的项目透明化方式更多的是白板。

无论是物理白板还是电子白板，大家把这个项目放在透明的环境里。很多的团队会做一个项目墙、任务墙，把所有的状态在墙上布置下来。还有一种方式就是电子白板，电子白板有很多的工具。

这两种方式都可以把你的项目风险暴露出来，项目透明化以后，其感兴趣的项目干系人都会来帮助我们这个团队，发现项目可能潜在的风险，同时会帮你解决掉。

记者：对，在Scrum会议的实践实际上是实践控制当中最重要的一件事件。

袁斌：没错。

记者：这更是团队做改进最佳的时机，那您认为Scrum会议在团队当中如何建立起来？在Scrum这块非常看重它有一个回顾会议，这个如何进行？

袁斌：回顾会议其实在Scrum里面起到了持续改进的最用，敏捷非常强调持续改进。

回顾会议在Scrum里面是持续改进的一个非常好的机会。但是现在能看到的是，回顾会议有很多时候团队流于形式了，觉得开的没有必要。更多的情况下我认为是，这时候回顾会议没有起到应有的作用。我认为一个回顾会议开的比较好首先是数据驱动，所谓数据驱动就是，我们通过数据去得到这个迭代里面哪些是最大的问题。找到问题以后，团队去分析它的根本原因，再去找到它的解决方案。然后把两三个好的解决方案，在下一个迭代里面去把它固化。回顾会议最核心的是根本问题的发现，所以我个人很推荐使用数据的方式。比如说Bug分类，计划和实际的偏差。比如说你每天八个小时的工作时间，你是三个小时有效工作，其他的五个小时我们可能会分析浪费在哪里？这些点都会把问题暴露出来。

记者：在Scrum会议中，除了回顾会议以外，还有没有其他的一些会议？

袁斌：就是Scrum里面？

记者：对，Scrum里面。

袁斌：Scrum里面其实有几个比较重要的会议，第一就是它的计划会议。在一个迭代开始的时候进行。计划会议是怎么样保证在迭代过程中间能够把所承诺的东西高质量的交付。第二个推荐的会议是每天早上的一个站立会议，15分钟。这个站立会议可以和我们前面你提到的白板一起使用，做到项目透明化。站立会议如果想开的好，最好所有成员在白板前面来开。这时候每一个成员都会把各自的工作状态和风险在白板上暴露出来。

还有一个会议是评审会，在迭代要结束的时候，我们来看这个迭代的交付是否能够满足迭代最开始的目标。然后就是回顾会议，回顾会议是最后我们要看哪些做的不好？哪些做的好？在下个阶段如何改进。

记者：在目前国内出现很多敏捷教练这个角色，您是一位资深敏捷教练，你认为敏捷教练在一个团队中，他主要的工作有哪些？而且敏捷教练在Scrum工作中建立起一个角色的转换。

袁斌：我觉得是这样，一个教练在一个团队里面，他最关键的是随时能够帮助敏捷在团队里面能够落地，包括敏捷的思想，敏捷的实践，能够让它落地。如果再细里说的话，它是能够帮助团队，通过敏捷的思想和实践解决团队现有的问题，这个也是我自己实际中的做法。也就是说，敏捷教练和团队一起来工作，通过敏捷的一些实践，也包括其它开发模式的优秀开发实践，来帮助团队解决问题。这时我认为敏捷教练最应该做的。

记者：在项目中他是一个不断持续改进地过程，不能按部就班地说，敏捷是怎么样就怎么样去要求他们这么做。

袁斌：对，因为很多敏捷实践背后是有假设的，它假设团队成员的技能达到什么程度，假设公司的文化会如何支持尊重、平等，但是这样的假设如果在项目中并不存在，如果我们把这些实践照搬过来，一定会有很多的冲突。

记者：在对未来几年敏捷开发的发展希望看到哪一些方向？