1、小项资讯
      关注项目管理领域的那些人和事儿，为您带来最新的管理政策、发展趋势；参与我们的讨论，让我们知道您的需求，为您答疑解惑、献计献策。

2、小项是谁？
      项目管理办公室的一群项目管理员，主要从事组织级项目管理工作，这是一群爱工作爱生活、积极乐观、极富责任心的人们。始终坚信：您的支持是我们服务的动力。

3、项目管理大家谈
      作为组织级项目管理员，我们打交道最多的是项目经理，最需要了解的是项目经理遇到的困难。通过前几期同大G、小新等采访对象的交流，我们对于项目经理眼中的“痛点”和“槽点”进行剖析，对新项目管理办法下工作流程的变化提出了更多可供改进之处。文章发表后，引起了很多项目经理、项目成员的共鸣，小项也收集很多切实可行的建议，在这里感谢大家的支持！

      被访谈人员均被隐去真名，这也是个小小的伏笔，等系列访谈结束后，我们将统一公布被访谈人员真名，敬请期待！

      本期我们采访到的是中心一位资深的项目经理Y先生，同时也是中心公认的技术、管理双料大拿，本次小项也是抱着虚心学习的态度，带领大家一起去了解一下，开发中心关于敏捷的那些事儿。

小项：Y先生，您好。首先感谢您接受我们的访谈。最近敏捷是业界大热的一个话题，听说咱们项目组也在尝试推行敏捷开发方式，能不能请您给我们介绍下大概情况。

Y先生：好的。其实对于敏捷方法的尝试，我们一直在路上。从最早的互联网银行开始，我们就引入了敏捷开发模式中的Kanban(看板)方法，对项目各个阶段的任务进行管理，大约进行了一年多，这个是我们最早期的敏捷尝试。

小项：说到Kanban，之前没有接触过敏捷领域的人来说可能还比较陌生，您能详细说说么？

Y先生：好。Kanban是敏捷开发（Agile Development）的一种方法，它最初起源于丰田公司的即时管理模式（JustIn Time， JIT），在软件研发管理领域，我们最常见的模式就是通过在项目工作场所的墙上张贴卡片来呈现和分享项目状态来实现对项目任务的管理。举个栗子，以下就是一个日常工作中典型的Kanban。

      在面板上，工程任务用卡片（即时贴）来代表，并通过把卡片贴在面板中不同区域来象征任务的状态，这些区域被标注为“pending(待办)”、“analysis（分析中）”、“development（开发）”、“test（测试）”、“deploy（发布）”，标注的名称可以根据需要而变化。同时，在每一列的最上方可以根据项目组情况标注可承受最大任务数WIP，这样的Kanban有利于可视化地跟踪任务并限制处理中任务的数量，根据项目组实际情况及时进行调整，真正做到团队自治和对项目进度的把控。对于项目经理而言，最担心的就是项目进度不可控，不知道每位开发人员具体的工作进度；对于开发经理而言，最担心的就是资源分配不合理，忙的人忙死，闲的人闲死，有了Kanban一切都是那么一目了然。对于开发人员而言，最担心的就是绩效考核不公平，“凭什么我做的比他多，拿的工资却比他少？不公平啊！”。通过Kanban的合理使用，这些问题基本都能得到解决。

小项：这么看来Kanban真是个不错的工具呢，这也正符合我们目前正在进行的项目精细化管理课题研究中涉及的理念。但说到敏捷，现在业界大热的，恐怕要说到SCRUM了，不知道咱们是否在项目中有引入此类方法呢？

Y先生：有的，SCRUM的核心在于快速交付和持续改进，我们在这之后更大规模的项目群中引入了SCRUM的管理方法。对于我们来说，不仅要考虑到中心对于项目群大版本投产的要求，同时也结合了各项目的实际情况，将整个项目生命周期划分为若干个迭代（2-4周），保证每个迭代结束都能提供一个完整可发布的版本，并快速得到反馈。我们会将合理的反馈内容纳入下一个迭代计划，对程序进行持续优化和改进。但是在当前阶段，鉴于项目群规模太大，具体涵盖到每个项目组的实际情况存在一定的差异，所以敏捷的实现也就比较局限，像用户故事、站会和回顾等等这些SCRUM普遍采用的方法，并没有在整个项目群的范围内实现。

小项：那现阶段我们是如何推行敏捷开发方式的呢？

Y先生：我们将SCRUM与Kanban两种方法相结合来实现项目开发过程中的敏捷转型。目前各项目组基本都是以2周为一个迭代周期，每个迭代开始时召开计划会议，制定本次迭代的任务目标和计划，让所有项目成员能在接下来的日子里更流畅地进行各自的工作。在这个会议上，项目经理会和团队一起对用户故事进行工作量评估，并拆分成具体的任务点，项目组成员根据自身情况主动领取任务，如果存在困难应该在这个会上提出，大家共同商议出解决方案。（迭代+计划会议+拆故事+领任务）

小项：用户故事，这是个新的概念，您能具体介绍一下么？

Y先生：用户故事（User Story）是从用户的角度来描述用户渴望得到的功能，对于敏捷开发来说，它是开发的基础。不同于传统的瀑布式开发方式，用户故事是把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务，它应遵循INVEST规则（Independent 独立性、Negotiable 可谈判性、Valueable 有价值性，Estimable 可估计性、Sized Right 合理的尺寸、Testable 可测试性）。

      用户故事的拆分有两个层面：大故事拆分成小故事，小故事拆分成任务。大故事拆解成小故事除了能通过“小规模化故事”防止小瀑布，同时也有助于识别出需求的某些细节；而小故事到任务的拆分，也就是我们常说的任务分解，可以看作类似瀑布模型中的详细设计，在这种方式中，每个任务都能在较短的时间（1-2天）完成，完成所有任务后能达到高质量实现用户故事的目的。有的人认为任务很难拆分，甚至没有必要拆分，这种思想就像是在瀑布开发模型中不做详细设计一般，设计思路还没有理清就扑入了代码的海洋，这种做法写出来的代码质量可想而知。任务分解同时可以用来制定工作计划，分解出来的任务就是在实现故事的过程中要做的事情，每个任务需要的时间就是做这些事情分别需要的时间。从这个角度来看，如果我们很够很好地将故事分解成任务，准确地评估故事的规模，无论是使用物理看板还是TFS等工具进行任务管理，都能较好地做好迭代计划并顺利执行。下面是一个简单的在线购书网站的用户故事拆分示例：

小项：那么采用用户故事评估出来的工作量会与中心目前采用的功能点估算结果相冲突么？

Y先生：这个情况我们也有考虑到，目前我们是以中心功能点估算的结果为依据，将工作量分配到以用户故事分解出来的任务下，所以不存在冲突的问题。

小项：了解了，那除了任务分解方面，咱们还有哪些其他做法与敏捷相关？取得的效果又如何呢？

Y先生：站会，这个非常重要。现在每天早上8点半到9点来我们办公室，会看到所有的小组基本都在开站立会议，这个会议很短，一般在15分钟以内，每个人只需要回答三个问题：上次会议后完成了什么？下次会议前需要完成什么？遇到什么困难和阻碍？这个步骤一般都是在看板前完成，各项任务可视化的讨论方式有利于对项目整体执行情况的把握，问题能够尽快地被发现和得到解决，保证项目按计划进行。另外还有每个迭代结束时的迭代评审和迭代回顾，这个我们通常作为一个会议来开，时间一般定在每个迭代结束的当日下午，在这个会议上大家会展示本阶段的项目成果，这是个重要沟通和反馈的过程，同时在这个会议中，会对本次迭代所有的故事、度量、事件从以下三方面进行归类：做的好的、做的不对的、改进意见。通过这个会议的开展，达到项目过程的不断改进和团队的不断进步。

      总之敏捷是一种思想，要想真正达到完全实现我们仍需不断探索，还是开头那句话：敏捷尝试，我们一直在路上。

小项：好的，这次的访谈就到这里吧，感谢Y先生带领我们了解了敏捷那些事儿，屏幕前的你有没有觉得受益匪浅呢？还是你也有些话不吐不快？如同前几期所说，项目管理方面不管您有任何的问题和疑问，或者是好的经验想要分享，欢迎联系小项，我们将会怀着最大的诚意，欢迎您的到来！

      （本资讯于2017-08-30首次发布）