|
敏捷开发方法的流行正是因为大家发现了传统瀑布方式无法适应从改变，革新而驱动企业的动态管理。如何在项目开发中能持续满足不断变化的用户需求让越来越多的开发和管理者受到了重视。敏捷开发成为了众多团队的制胜之道。下面，我们专访了北京迅思威尔科技有限公司的资深敏捷教练袁斌老师给网友们分享了敏捷在项目实践中的一些经验。blog.mypm.net
项目管理者联盟
袁斌，工学硕士、MBA， Scrum、AUP、Agile modeling、XP、kanban等资深实践者，资深敏捷教练。近20年中就职于全球性公司从事软件和产品的开发。曾任Anoto产品和Mino产品中国区软件开发总监，利用Agile & Lean实现产品快速交付，应对变化的需求。超过8年敏捷开发&精益开发的实践过程中，在电信行业、外包团队、互联网产品等多个行业积累了丰富的经验。
以下是视频采访文字实录：项目管理者联盟
记者：大家好，今天我们请到的嘉宾是北京迅思威尔科技有限公司的资深敏捷教练袁斌老师。跟我们讲解敏捷开发项目实践中一些主要问题，以及对未来几年敏捷发展这一块的一些看法进行分享。首先请袁老师跟网友们做一下自我介绍。项目经理圈子
袁斌：大家好，我是袁斌，来自迅思威尔，我自己有超过八年的敏捷的实践经验，所以我对自己的定位是一个资深的敏捷实践者。OK，谢谢。
记者：那么在敏捷当中，很多人都看到了它的成本控制，它能够降低项目开发中的一些浪费。但是往往适得其反，不但没有降低，反而增加了开发成本。在开发成本控制这一块，你怎么去理解?项目管理者联盟
袁斌：其实对于成本来言，每一种新的方法一定会有它的学习曲线和学习成本，往往在开始的时候，它的结果会比现有的情况还要糟糕，它会有一个U形的曲线。所以这里面更多的是怎么样降低你的学习成本和学习曲线。如果在最开始使用敏捷的时候全盘采用整个敏捷开发实践集合，较高的学习成本和学习曲线会使实施敏捷的效果大打折扣。所以我这里的建议是，对成本控制而言，首先找你在研发过程中间最大的痛点，在痛点的基础上，然后在敏捷开发的众多实践里面去找针对这个痛点的实践集合。这个实践集合的原则就是学习成本要低，而且它能够持续改进，对你的痛点起的效用最好。这样的话，不断地改进，持续控制成本，就可以获得让人满意的投资回报率。blog.mypm.net
记者：在敏捷实践过程当中，是否使用到一些敏捷工具，能否推荐一些比较好的工具?项目管理者联盟文章
袁斌：敏捷工具是这样考量的：看你产品的周期，如果你产品周期相对比较短，比如说你两三个月，那么我个人并不建议用敏捷工具来考量、管理你的敏捷开发的过程。如果是周期比较长的话，我是建议用敏捷管理工具。因为原因主要在于，第一，你要去积累很多数据，这些数据会有利于分析你的过程中间，哪些是好的?哪些是不好的?，然后有针对性的改进;第二，对于整体的需求管理，包括你一些技术方案的管理，需要一个工具能把它整体管理起来。项目管理者联盟
记者：在项目当中，敏捷测试人员的职责和一些技能的要求是什么样的?项目管理者联盟
袁斌：我觉得在敏捷的开发过程中间，测试人员更多的是能够帮助团队，帮助团队最后的交付能够有一个保证。所以说敏捷的测试人员首先应该是尽早测试，更早地在测试周期的前面进入。比如说在一个迭代开始的时候，在计划会议他就能够介入，他给出很多从用户层面对需求的看法，能够帮助团队更好的了解需求。同时通过把握测试的风险，尽早的给研发团队“bug出现风险高”以及“用户使用频率高”两个层面的用例，帮助团队控制研发过程中间的风险。项目管理者联盟
我觉得还有一个很重要的是持续地测试，能够去帮助团队，特别是研发团队，不但是说我能够尽早，而且不断地持续地进行这些测试，及时的把风险反馈给研发团队。club.mypm.net
记者：据我了解，很多朋友说你在测试这一块，好像是他们不需要专门的测试人员，你觉得这样的公司对于开发一个项目的时候，有没有什么影响?项目管理者联盟
袁斌：有一些公司会有，比如说像Facebook，它会说我没有专职的测试人员，它是工程师文化。但我个人认为在我看到的很多项目里面，测试人员是必要的。我说一下我的观点，我觉得如果没有测试人员对工程师的要求非常高，因为他要承担专业测试人员的技能。service.mypm.net
记者：对他个人的一些技能，什么要求都会高。项目管理者联盟
袁斌：对，我觉得术业有专攻，测试人员更多的从用户的场景对产品进行测试，特别在非功能性需求的测试，这方面的专业技能要求也是很高的。项目管理者联盟
记者：做到敏捷开发，每个团队都要经历一个转型期，在转型期还需要每个团队根据自身的不同找出合理有效的解决方法，一般是如何处理这个问题?项目管理者联盟
袁斌：团队在做转型的时候，我们看到的很多团队，包括我们自己的客户，最大的问题在于，敏捷开发有很多的实践，如果把所有的实践都拿过来。然后全部用在团队中间，但是每个实践都有学习成本。所以说都拿过来以后，团队很抵触，而且也不能解决团队的实际问题。因为太多了实践以后，大家觉得很疲惫，有时候适得其反。我个人的建议是这样子，在转型期的时候，用痛点驱动的方法。所谓痛点驱动就是，找到团队目前一个很严重的痛点，在敏捷实践中间，找一些实践集合，不要全都找，是找一些实践集合，去把痛点解决掉。然后再看下一个迭代的时候，继续找目前最大的痛点，然后再用一些实践集合把它解决掉。你不断地这样去做的时候，团队抵触很小，他觉得OK，把我的实际问题解决掉了，他会很愿意采纳敏捷。项目管理者联盟
记者：您刚才说痛点驱动，能否解释一下?项目管理者联盟
袁斌：所谓痛点驱动，痛点其实就是最大的问题，是我在研发过程中间碰到的最大问题。比如说我可能在这个过程中间，我最大的问题是迭代交付延期。项目管理者联盟
记者：延期?项目经理圈子
袁斌：对，我延期了，也有可能最大的问题是对需求了解很差，或者说人员流动是一个最大的问题。那么比如说人员流动是一个很大的问题，这个时候敏捷实践里面，你不见得非要用测试驱动开发，要用用户故事描述需求，可能是结对编程，可能是团队的代码负责会更有效。也可以强调计划会议里面整个团队都要参加讨论，减少学习债务。这些实践可能是对你当下的痛点会有更大的帮助，建议首先采用这些实践，我的观点是这样的。项目管理者联盟
记者：敏捷过程当中，我认为最重要的是一个需求、拆分与分工，你能谈谈如何进行它需求合理地拆分，以及分工吗?项目管理者联盟
袁斌：我的观点是，如果是需求的话，尽量采用一种拉的方式，所谓拉的方式是说，我们研发的流程就是从需求分析、再到设计、编码测试、然后交付客户。我的观点是，我们应该是从客户这一端开始，客户这边认为，他最需要的是哪些需求，然后对这些需求做比较详细地拆分。所以这样在Scrum里面，它有一个叫做Product Backlog，翻译过来叫需求列表。项目管理者联盟
这个需求列表里面高优先级，一定是客户最想要的，所以需求拆分我建议从高优先级的，对用户价值最大的需求拆分会比较好一点。项目管理论坛
|
