又一个要被互联网产品湮灭的职业：项目经理_网易财经
又一个要被互联网产品湮灭的职业：项目经理
用微信扫码二维码
分享至好友和朋友圈
看板流程的下面这三个重大组成部分，已经宣判了项目经理这个角色的死刑...
开门见山的说吧：我喜欢看板。但主要原因并非人们常说的那一套：既不是因为它是一个可视化的管理工具，也不是因为它能帮我们更好的对进度进行把控，更不是因为它所谓的自我管理的优秀特性。我喜欢看板的主要原因其实很简单，就是因为它让我在我的产品打造团队中根本不需要引入额外的项目管理的角色。
我曾经担任过这个角色，深知项目管理是个很复杂的活。在传统的方式中，客户常会问我拿项目进展的甘特图，而事实上是我们根本搞不清楚它们的里程碑是怎么回事；我经常要处理的是项目管理的风险，而事实上我们更需要关心的应该是客户成功(Customer Success)；在项目管理中我们更看重的管理者认证水平，而在精益管理中我们更需要看重的是管理者为产品和公司所带来的增值。
就拿我们的&Resultados Digitais这个产品为例，通过高效的运用看板，意味着我们根本不需要项目经理这个角色的存在。但这不意味着我们不相信“项目” -- 只是为了将其与传统的项目管理意味中的”项目“区分开来，我们将我们的“项目”称作“史诗(Epics)“。
那么使用看板究竟能给我们带来哪些好处呢？
项目vs流程
相对于项目管理，我更喜欢看板的主要原因之一就是，项目管理关注的是项目，而看板关注的是流程，是程序。
流程作为精益管理巨大的优势之一，翻译到如看板等工具上面就是，它强调的是打造并维护一个可以允许不同的“包(Pakcage)”以相同的质量进行通过的流程。这里关注的改进之处永远都是在流程方面，所以在这个过程中所获得的经验和教训都必须是可以应用到整个流程上面，而不仅仅是当前正在通过该流程的某个特定的项目，某个特定的“包”上面。通过这种方式，你在持续改进方面所付出的努力将会在任何时候都能体现出效果。
看板流程的下面这三个重大组成部分，至少在我看来，已经宣判了项目经理这个角色的死刑。关于看板和Scrum的更多描述，请查看文章《Scrum vs. 看板，还是Scrum + 看板？》。
完成的定义(Definition of Done)
"完成的定义“是每个阶段的目标。这是”内部客户(比如，下一个阶段)“希望前一阶段所交付的内容。这是你在你的看板流程中为每个阶段进行角色设计的一个方法，且，更重要的是，它保证了通过看板流程的所有“包”的质量。“完成的定义”为在项目的进展过程中大家究竟需要瞄准什么样的目标提供了指导方针。它定义了团队在看板流程的每个阶段中所要努力达成的目标，却又不对完成该目标的方法进行限制。
对于打造一个伟大的产品，发现问题并正确的理解该问题是至关重要的。事实上，没有正确的对问题进行认识往往是一个产品所以失败的主要原因之一。所以，作为一个不断迭代循环和改进的过程，我们在每个项目中进行学习，对每个阶段的“完成的定义”进行改进。通过这种方式，每个“包”通过这个流程时所给我们带来的知识，都能应用到所有紧跟着的“包”上面来，以确保同样的错误不会出现两次 -- 这又是另外一个精益管理上非常重要的因数。
流程的持续改进
说起来天下第一，做起来有心无力！针对流程而非流通这个流程的“包”进行突破，这听上去是非常反直觉的，但是在精益管理上面，这对你的产品又是至关重要的。
举个例子，在发布一个新功能的过程中，你发现大量的用户生成了大量的需要客服支持的凭证，抱怨说他们不知道如何运用这个新功能。那么因为一次用户教育的失败，这就有可能会影响到用户的参与度(engagement)。此时你的技术支持团队应该已经开始着手帮助这些客户解答他们的疑问，同时你的开发团队应该也在动手提供一个针对性的更新。但正重要的是，精益管理会迫使你去找出究竟哪个环节出了问题，然后迫使你对这个流程进行改进，这样才能避免同样的错误不会在其他地方(项目，功能，增强，“包”，等等)再次发生。比如，在内测环节？易用性测试环节？还是在早期的解决方案设计环节？
持续改进是确保其他项目不会犯同样的错误的关键，所以请记得将其应用到你的流程上面去。
流程，就是你打造你的产品或完成你的项目的方式。流程的设计很大程度表示了你的团队如何开发你的产品，同时它也反映了你的团队及你的公司所宣扬的价值取向。
世上并没有一个统一的标准来告诉你该如何定义你的看板流程，但根据你的产品的需要，倒是有着不少来自其他地方的值得借鉴的优秀实践。同时，随着你的生意的成长和你的产品的日催成熟，你的看板流程也会相应的跟着改变。我们为我们的产品打造MVP时候所用到的看板流程，和现在我们在用的看板流程已经相去甚远。回首当年，我们那时对产品的的认知还相当有局限性，且我们当时是一个只有10个人的团队(相比我们现在，可以说是个小团队了)，随着我们对产品的深入学习和认识，团队成员也随之达到了200多号人，所以我们面临的挑战也是不可同日而语的。
你的流程进行设计和改进应该源于你此前的学习成果，但也需要正确的反映你的公司的价值取向。确保你对你的生意，你的雇员，以及公司的价值取向有正确的认识。通过以提升和加强你希望在你的团队和产品中看到的价值取向的方式来使用你的流程。这同时还会是一个传播你的企业文化的非常强大的工具。
以上提到的这些好处只是看板所带来的众多好处的冰山一角。看板的使用以及精益管理的原则，对于产品开发以及团队的持续交付来说，都有着极高的价值。所以我们应该从今天开始尝试在你的产品打造过程中应用上看板流程，并且确保不断的在学习的过程中改进你的看板流程。
英文版来自Medium，中文版由天地会珠海分舵进行独家编译
本文来源：钛媒体
责任编辑：王晓易_NE0011
用微信扫码二维码
分享至好友和朋友圈
加载更多新闻
热门产品:　　　
:　　　　　　　　
:　　　　　　　　　
热门影院：
阅读下一篇
用微信扫描二维码
分享至好友和朋友圈通过前面几篇关于敏捷开发总体的相关介绍，相信大家对敏捷开发模式已经有了一个比较清晰的了解，后续会介绍一些比较细分的方面，结合我在敏捷开发实施过程当中的一些体会，来阐述自身对敏捷开发的认识。
敏捷开发中的PO即Product Owner，字面意思是产品或业务负责人，即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员，一般可由产品经理担任，也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的（指一个办公室内坐在一起的），建议由产品经理担任，本身产品经理已经是所有业务的接口人，熟悉业务是其本职工作；如果产品经理和开发、测试团队是两地办公的，如设立的研发中心、外包服务等形式的，建议在开发团队内指定一个人来担任PO，这样产品经理在第一次PRD全体review之后，只需跟这个PO讲解清楚产品逻辑，后续开发和测试当中遇到的问题，都可以咨询PO来得到解决，PO不确定的可以联系产品经理确认，这样可以减少一部分的沟通成本。
敏捷开发中的SM即Scrum Master，字面意思是敏捷专家或者敏捷大师，即熟悉敏捷开发模式及敏捷实施流程的人员，一般可由敏捷团队当中的开发负责人担任，部分能力很强且懂技术的产品经理也可担任这个角色，因涉及到工作量评估和分派等工作，最好都是由技术能力较强的人员担任。
Product Owner（PO）
Product Owner角色定义
确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI（profitability of product）负责。 是维护产品需求清单（ product backlog ）的人，代表利益相关者的利益。
Product Owner工作职责
负责最大化产品以及开发团队工作的价值。主要职责如下：
1、确定产品的功能；
2、决定发布的日期和发布内容；
3、为产品的ROI负责；
4、根据市场价值确定功能优先级；
5、每个sprint中，根据需要调整功能和优先级（每个sprint开始前调整）；
6、接受或拒绝开发团队的工作成果；
7、参与Scrum Planning Meetings（Sprint计划会议），Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）
Product Owner在团队中的作用
在junior团队中：主要的需求来源，个人确定需求价值和优先级
在intermediate团队中：多角度的收集需求，和团队成员共同确定需求的价值和优先级
在Senior团队中：和团队成员共同提出和收集需求，共同对产品负责
这里的团队分级主要是指团队的敏捷成熟度，即产品团队实施敏捷开发模式后，对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。
一句话总结PO这个角色就是：告诉产品团队要做什么，做功能的先后顺序是怎样的，需求有变动时该如何处理。
Scrum Master（SM）
Scrum Master角色定义
是团队的导师和组织者，与Product Owner紧密合作，及时为团队成员提供帮助。促使team按照scrum方式运行，为Scrum过程负责的人。
Scrum Master并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者，他是Scrum团队中的服务型领导。
Scrum Master工作职责
确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下：
1、保证团队资源合理利用；
2、保证各个角色及职责良好协作；
3、解决团队开发中的障碍；
4、作为团队和团队外部的接口，协调解决沟通中的问题；
5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）。
Scrum Master在团队中的作用
在junior团队中：主导和控制
在intermediate团队中：引导和教导
在Senior团队中：辅导和协助
一句话总结SM这个角色就是：教整个团队怎么做，如何估时，跟进每天进度，风险控制，定期总结，计划排定。
某Team在Plan Meeting会议中，邀请了PO参加，但PO因会议时间冲突未能参加，在讨论Sprint? Backlog的时候，因需求有变动，团队未完全按照product? backlog上的优先级去拿，选好Sprint? Backlog 后，Scrum master详细讲解了每一条Sprint? Backlog应该如何拆分及理由，最后给出了每个task的评估工时。
问题一：PO未参加计划会
应与PO提前协商时间，若PO没有时间需调整时间，PO一定要参加；
问题二：未按已排定的优先级做
如果不按照product? backlog上的优先级去拿需要和PO一起决定；
问题三：SM一个人完成需求拆分和工时评估
任务的拆分及工时的评估需要和团队共同确定，不是Scrum master一个人说了算。
在敏捷开发团队内部，PO和SM角色是非常重要的，基本决定了团队是否可以很好的执行敏捷开发这种模式，因此这两个角色一定都要十分熟悉敏捷开发的整个运转流程，带领和引导团队一步一步的往敏捷的方向迈进。很多时候PO和SM的不专业，很容易使团队偏离敏捷的模式，因此决定一个团队能否完全进入敏捷开发模式时，这两个角色很关键。
零起点做产品经理微信号：zeropm酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
Scrum这个词是来自于英式橄榄球，是指两个前锋互相争球的情况。我想Scrum的创始人Ken Schwaber肯定是一个橄榄球迷，呵呵&.，这是题外话。先简单介绍一下，Scrum一种敏捷项目管理的框架，它的核心是迭代和增量。Scrum中有三种角色：产品经理(Product Owner)，ScrumMaster(相当于项目经理)，团队(Team)。具体流程如图：
&产品经理整理出按优先级排序的产品Backlog(产品需求列表)，然后召开Sprint(开发周期)计划会议确定当前要进入的一个Sprint的Sprint Backlog(选中产品Backlog的需求)，进入Sprint开发，每日需要进行Scrum例会已检查项目当前进度和遇到的问题，Sprint完成之后是Sprint评审会议，已检查Sprint产出的功能增量，最后是Sprint总结会议，总结Sprint中的经验和问题，已改善流程提高效率，把待改进的高优先级的事项加入到下一个Sprint Backlog中。
我觉得Scrum很好的诠释了戴明的PDCA(plan-do-check-adjust)循环，就整个迭代来讲，Sprint计划会议对应Plan，Sprint对应Do，Sprint评审会议和Sprint总结里面做了check和adjust。那么在Sprint里面，每日的Scrum简会处理三个问题：1、前一天做了什么？2、今天将要做什么？3、遇到了什么障碍？那么在这里面做了plan今天的事情，check前一天做的事情和遇到的障碍，do今天的事情，如果有障碍那么就需要adjust。
另外Scrum的三大特点也让我比较振奋，也是它和传统瀑布式的项目管理的最大区别。
&一、&可能性的&艺术
&强调想事情的时候不应该把注意力集中在&不能做的事情&上，而是关注当下&什么事情可以做或者可能做&，不要被诸多的不确定性因素所困扰，先做可以做的，然后看有什么新的发现，有什么新的思维出现。
二、团队自组织，自管理
强调&放权&，让团队自己寻找解决问题的最佳方案。可以激发团队创造力，增强团队责任感，显著提高生产力。
三、面对面沟通
强调面对面的沟通，以有效减少沟通障碍。
如果你公司的项目在原来的管理方式下无法运行了，请试试Scrum吧！
本文来自：
& 相关主题：&&&CSM认证培训.课程主办：ShineScrum开课时间: ~ 16,
09:00 ~ 17:00城市:上海市南京西路88号上海新世界丽笙大酒店讲师:Jens ?stergaard秦风&（中文助教现场支持）价格:RMB 7000元/位，团体及提早报名优惠多多课程概述在这两天的ScrumMaster认证课程中，学员将从实际操作的层面上掌握Scrum的运用技巧，学员将学会如何避免Scrum实施过程中的一些常见问题。Scrum的规则很少，但要掌握其精髓却并非容易，从资深Scrum大师那里答疑解惑，获取有效的实践经验，通过练习亲身体会Scrum的工作方式非常重要。课程中通过一个59分钟的模拟Scrum项目、XP Game等大量穿插的实例、练习、讨论等让学员亲历Scrum的工作过程、领悟Scrum的内涵、掌握Scrum的精髓。你的工作方式的改变从这里开始。ScrumMaster被评为2017年最具前景的20类工作之一，成为认证的ScrumMaster有助您成为组织敏捷转型的推动者、领导者，是您新的职业生涯的迈出的第一步。证书由美国Scrum官方机构Scrum联盟颁发。课程特色全球首位CSP, 最早的认证Scrum培训师之一、知名的世界级Scrum大师Jens Ostergaard授课内容全面、深入, 重在实际操作及运用囊括了大量项目论证过的实践经验课程过程中穿插丰富的实践练习、时间多达50%以上课程受众软件开发人员，测试人员，团队成员，架构师，项目经理，副项目经理和其他对敏捷软件开发和Scrum感兴趣的人员。课程收益Scrum Alliance颁发的ScrumMaster认证证书，成为一名认证的Scrum MasterScrum Alliance的两年会员会费及会员资格，与Scrum Alliance世界各地的Scrum 专家探讨学习ShineScrum捷行终身荣誉会员资格，可免费参加ShineScrum捷行终身荣誉会员资格主办的各种活动一副价值30元的估算扑克一份CSM课程纸质版中英文讲义Scrum实施模板及大量参考资料推荐美国项目管理协会（PMI）学分 16 PDUs学员反馈联系方式Tel:400 920 0024Email:ShineScrum（上海总部）上海市闵行区联航路1588号（上海国家现代服务业软件产业化基地）业务楼1B 308室ShineScrum（北京办公室）北京市海淀区中关村南大街7号（理工小白楼220室）课程大纲软件项目的复杂性敏捷宣言及其价值观、究竟什么是敏捷Scrum概述-Scrum的理论基础、历史、框架及流程Scrum角色破解理解潜在可交付“Done”的定义如何做计划如何做回顾和反馈Scrum Master的一天“59分钟”的模拟Scrum练习产品负责人破解管理人员破解Scrum会议破解终止一个Sprint发布管理大型团队和项目的Scrum实施、异地团队的Scrum实施Scrum和XPScrum和CMMiJens ?stergaard秦风讲师Jens ?stergaard秦风世界级Scrum培训大师CST、House of Scrum创始人、ShineScrum共同创办人Jens是全球首位认证Scrum专家和全球最早的认证Scrum培训师之一；他有20多年软件行业的从业经验，Scrum管理和实践的经验。自2004年在哥本哈根取得CST认证后，Jens在欧洲各国教授Scrum培训课程。至今，他已经在全球范围内培养并认证了一万余名学员，每12个Scrum Master中就有一位是他的学生，他也是全球最受欢迎的Scrum讲师之一。
从普通开发人员、DBA、团队lead、项目经理，直至成为一名Scrum Master，在金融领域二十多年的稳步成长使Jens能准确理解和把握Scrum团队里不同的角色可能面临的问题、挑战和机遇，从而制定出相应的培训内容和辅导方式。Jens认为纯粹的Scrum有助于促进整个开发进程的完善，并致力于推行Scrum在公司组织内部的实践。
2008年，他和Scrum的创始人之一Jeff Sutherland博士一起创办了Scrum Foundation。 Scrum Foundation的课程遍布美国、加拿大、荷兰、丹麦、英国、德国、澳大利亚、新加波、印度等国家；客户涵盖谷歌，微软、惠普、IBM、Oracle等。
2010年，Jens开始为中国的敏捷爱好者和从业人员授课。五年的时间里，他更多的了解和体会到了中国文化和中国软件从业人员所处的环境和现状，同时不断调整自己的授课方法以及内容，使之更贴合国内学员的需求。
Jens致力于推动最新的敏捷/Scrum理论和实践在中国的普及应用，使国内的开发人员、企业能够接触和运用敏捷进行开发、管理和运营，并且最终能够成为敏捷的人和敏捷的企业。授课场景
微信扫一扫，免费获取Scrum敏捷框架导入实施方案，敏捷开发资料及案例、海量国际前沿敏捷动态、实践好文及心得、线上线下敏捷活动分享和最新课程排期此页面上的内容需要较新版本的 Adobe Flash Player。
最新开发文章
最新信息推荐
上市公司专栏
实时股价每分更新
纳斯达克（美元）（市值：亿美元）
综指：　涨跌幅：
恒生指数（港币）（市值：亿港币）
综指：　涨跌幅：
综指：　涨跌幅：
Scrum的中国式生存
作者：青猫来源：游戏创造02-24-2010
　　Scrum，这只敏捷家族中的生力军，现在正被越来越多的人认识并且接受。在游戏开发领域中，近年来国内的许多企业也开始尝试采用Scrum进行游戏开发。Scrum这种强调频繁交付紧密沟通的开发方式似乎证明了比它的前辈们更适合游戏开发领域。但正如人月神话中的那句老话“No silver bullet”。那么对于如今国内占主流的大型多人在线游戏（MMO）开发领域而言，Scrum是否就是那枚传说中的银弹，一经发射，就能让摆在你面前的所有问题都瞬间灰飞烟灭？我们在具体的执行层面又应该怎么去控制和管理它呢？笔者希望以下的文字能帮助你解答以上两个问题。
　　Scrum与传统方式之间的不同
　　在使用Scrum之前，公司或者开发团队多多少少已经有一些成型并且大家都已经习惯的开发模式。打个比方说，策划先行，然后召集大家讨论策划案，之后得出程序和美术的工作量再定义出里程碑拟订好开发计划，然后大家开始正式分头动工。在这个开发流程中，开发人员面临的最大困难是策划案也就是需求的变化量非常大，并且这种变更，很大一部分情况可能是直到里程碑快结束的时候，大家才一起意识到有些功能压根就无法实现或者勉强实现的效果并不理想。这时似乎只剩下修改策划案这一条路。于是大家对于无论如何严格的审核策划案，到中途总是会以这样那样的理由变更的情况已经习以为常。因为需求变更而导致产品推出时间可能一推再推，以至于最后不得不砍掉一些功能才能确保产品在可以接受的时间之内被推出。
　　尽管传统的开发方式可能有些地方老是出问题，但大多数情况下大家也会比较倾向于下次注意点，而不是尝试一套新的开发方法。在MMO的开发模式的选择上，Scrum在许多地方的确可以解决传统模式所遇到的问题，比如Scrum能在拥抱变化这一点上极大的帮助开发者。类似这样的优点，在Scrum的拥护派看来，可以列出好几页来。但是，要说服一个原有的团队选择一种新的开发模式来代替大家已经熟悉的方式，光列举优点是不够的，我们也需要直面Scrum与现有模式的其他差别，有些甚至是Scrum的劣势。
　　1． 每次提交可运行的版本
　　Scrum的精髓在于拥抱变化，并强调通过频繁的交付来获得及时的反馈，以便于尽可能快的调整不合理的需求。但对于某些大型MMO而言，比如MMORPG，系统的复杂度往往超出我们的想象。如果没有一款已经使用过的引擎，光是前期对低层技术的开发就是一个漫长的过程，如果采取Scrum的方式，要求每一小段时间提供一个可运行的版本无疑是一个噩梦。而对于同时进行的策划案的撰写，要求提供一个反应策划内容的版本更是困难。Scrum在这个阶段如何开展，是需要克服的一个问题。
　　2． Sprint的划分
　　相对于传统的基于里程碑的开发，Scrum要求划分出一个个相对较短的Sprint。并且每个Sprint需要有可以提交的版本，以及一个比较明确的可以体验的目标。而在MMO的开发中许多工作，比如系统架构设计，数据库设计，美术概念讨论等都很难在Sprint中体现出来，也就无法通过Sprint Review的形式获得反馈。但是这些东西又跟所有的人的工作息息相关。Scrum如何在能够保持紧密沟通的同时，对类似的相对独立的部分也照顾周全？
　　3． Scrum的管理
　　Scrum是一个强调自我管理的开发方式。无论是Stand Up Meeting还是Sprint Planning的时候都要求少干涉多聆听。对于项目经理来说，某些时候参与感很差，总是好像找不到自己在团队中合适的位置。但是项目经理又不得不对进度负责，面对各个并行的小组，每天都可能有大量新的task提出，又有大量task被否决，如果你这个时候去问项目经理“我们到底能不能按时完成，如果推迟，那还需要多久”这样的问题的话，他也许只能对你摇摇头。我们在使用Scrum的时候，进度管理上的缺失也是我们需要直接面对的问题。
　　类似的问题，在我们推广Scrum的时候可能会遇到很多。为什么会有如此的问题归纳一下，原因可能如下：
　　1． Scrum最早来自于软件工程，虽然现在扩展到开发的各个方面，由于其自身的限制性，注定要面临许多困难。（笔者曾经听说过某公司号称用Scrum进行管理，要求销售，HR部门都实行Scrum方式，很难想象这是一种怎么样的Scrum。）
　　2． MMO开发本身结合了跨平台，分布式，周期长，变动大等多个开发难题， Scrum能够很好的解决一些问题，但对需要长期规划的问题明显缺乏控制力。
　　融合：和其光 避其尘
　　在笔者看来，Scrum是一种优秀的开发方法，许多特征的确证明了它比它的前辈们更好的解决了游戏开发中所遇到的诸多问题。可是，如同它的前辈一样，Scrum并不是游戏开发中的那颗Sliver Bullet，再次应征了Brooks大师所言。所幸的是，我们可以使用Scrum与传统开发方式“混血”式执行的办法，根据自身情况，灵活的选择有利的方面执行，对不适应的地方进行改进，从而能最大限度的在MMO游戏的开发中发挥出Scrum的威力。
　　笔者有幸在参与的一些项目中使用过Scrum方法，同样也经历了Scrum与本土MMO开发结合时候遭遇的种种尴尬。笔者认为，Scrum对于MMO游戏的开发，有其利也有其弊，对于整体进度的把握以及对于文档工作的控制Scrum做得并不是十分到位。对于任何一种开发方法论而言，执行团队都需要从自身实际的条件出发，选择性的使用。最怕的是盲目执行，暴力式地推行，而其他软件的工作却不跟上，执行的团队并不明其所以，最后可能搞得人人谈敏捷而色变，失败当然是一个必然的结果。笔者始终认为，工具，方法始终是死的，如何使用才是真正出学问的地方，只有从自己实际出发，冷静分析，在合适的地方用合适的工具，才能做到庖丁解牛，游刃有余。
　　那么Scrum应该如何结合传统的MMO开发方式呢？我们从项目开发的各个阶段来一一分析，如何让Scrum发挥自己的威力。
　　项目前期
　　项目前期我们面临的问题有哪些？首先是产品尚未成型，团队也许对将要制作的产品并没有一个十分清晰的概念，更谈不上对项目规模的预估。其次有一大堆技术性的难题摆在团队面前。这些难题能否解决，如何解决，都势必会对策划案的成型有决定性的影响。这个时候，我们可以分两头采取不同的开发模式。
　　对于将面对的技术难题，这个时候目标明确，团队规模较小。比较适合采用Scrum的形式一一攻克这些问题。我们可以把大家公认会遇到的难题列举出来，通过Scrum Planning的形式分解成一个个User Story再划定各个问题的优先级和互相的依赖关系，然后分别组建Scrum团队。这个时候的目标很明确，即得到这些难题的解决方案。我们希望在这个阶段结束的时候，程序对所要面对的技术问题心中有数，策划也对哪些能做哪些不能做有一个清楚的认识。同时我们还希望对一些我们必须要克服的东西，在这个阶段已经能产生一些行之有效的工作流程。
　　对于Scrum小组的组建，这个阶段我们可以以程序为主，策划和美术作为某些User Story的Customer，负责对程序工作成果的审查。为避免过早的陷入需求更改的陷阱，这个时候策划除了验收成果之外，不应过多的干涉程序实现的方法，而仅仅在设计User Story的时候提出自己的意见（事实上很多User Story应该由策划和美术直接提出）。在Sprint的划分上，我们可以以2～4周的标准划分。尽量将这个阶段控制在2～4个Sprint之内（这取决于团队的大小和技术基础）。对于一些经过验证存在困难的User Story可以在每个Sprint Review结束后的Planning Meeting上经大家讨论做少许更改，让下一个Sprint向更接近我们的目标（切实可行的解决方案）的方向上前进。对于Scrum的范围，笔者建议尽量不涉及高耦合的工作，将涉及多个方面的User Story拆分成相对独立的部分再分头进行。举个例子来说，可以将服务器端和客户端的技术难题分开进行，对于涉及服务器端和客户端交互的功能再单独提出来作为一个Scrum，尽量保证工作的粒度比较小，减少互相依赖的关系。我们的首要目标是证明技术可行性，这对整个流程的开展有一定的好处。
　　对于策划案以及美术风格的概念设计，这个时候则采取较为传统的方式，由策划和美术师内部产生。策划在对程序的Scrum小组提出User Story的同时即提出了自己的疑问，在程序执行Sprint的过程中获得对自己提出问题的反馈，进而决定自己的策划案如何撰写。美术则在这个时候确定美术风格，以及在与程序Scrum小组合作的过程中确定某些美术工作的工作流程。笔者不建议这个时候就加入程序对策划案进行讨论，这也许和某些团队采取的方式不同。这种方式对策划和美术的要求较高，既需要向程序的Scrum小组提出User Story，并从审查中获得反馈；也需要保持设计工作的相对独立，做好策划案的前期工作。这需要策划或美术在前期就对中期可能发生的问题有所预见，向程序有针对性的提出需要测试的地方而不是等待程序来告诉你不可行。如果这个时候能有富有经验的产品经理或者制作人来负责这两方面的协调工作，也是一个确保这个过程可以顺利进行的有效因素。对于程序美术在前期就加入讨论，笔者是持保留意见的。比如曾经经历过的一个项目就因为太早冻结策划案以至于美术和程序花了几天来讨论每个UI元素的具体坐标是多少，但最后却不得不尴尬的面临因为用户体验不友好而更改UI方案的情况。
　　在这个阶段结束的时候，我们应该得到一个策划案的初稿，起码完成了整个系统以及世界的架构，可以估计出项目将来在程序，美术和策划工作上的规模。还应该有几套行之有效的工作流程，能根据项目的预计规模估计出将要投入的人力和项目需要进行的时间，以便于之后的市场等多项工作的计划和开展。接着，我们就便可以投入更多资源进入正式开发的阶段。
　　项目中期
　　在MMO项目中期，我们面对的主要问题是对整体进度的把握，确保能按时推出我们需要的版本。其中面临最主要的难题就是对需求变更的控制。这个方面Scrum有其决定性的优势，但如何在高度拥抱变化的同时又不失对进度的把握是Scrum在这个阶段所要面临的问题。笔者建议这个时候需要根据团队对Scrum的熟悉程度来选择不同的解决办法，分别采取以Scrum方式为主导传统方式为辅的方式，或者反之。
　　对于一个熟悉Scrum的团队而言，笔者的建议是在正式开发之前，整个团队坐在一起，讨论策划案。将策划案中划分的各种系统分解为不同阶段的User Story，再通过团队之间的讨论以及各组之间的工作配合需要制定出优先级。现在我们有了一大堆由策划案分解出来的User Story，这些User Story有一定的依赖关系和不同的优先级，这时候根据我们的需要将这些User Story组合成不同的Sprint，再视这些Sprint的目标和内容组合成不同组合，每个组合我们可以视之为一个里程碑。如果你的项目的时间预算非常有限，你可能会倾向于将一些不是很重要但如果不完成其他部门就无法开展工作的User Story先行制作；如果你的时间充裕，你则可能更倾向于先有一个完备的系统设计以及一个方便扩充的灵活架构，让其他部门暂时等待或者做其他的事情。总之，这一切取决于项目具体的需要和团队资源，并没有孰是孰非之分。
　　由User Story来构建里程碑这对团队的Scrum能力而言是一个考验，需要团队对User Story乃至Sprint的划分有一定经验，并且能够预见整个过程中可能面临的风险。选择合适，制定好的，可实现的User Story可以规避很多由于后期Sprint变更时候带来的连锁反应。这也是为什么笔者建议有一定Scrum经验的团队选用该方法的原因。
　　对于初次尝试Scrum的团队，可以尝试采取相对保守的方法。通过传统的方式对策划案进行技术评估后，划分出里程碑，然后根据每个里程碑的目标制定User Story，再划分Sprint。这在一定程度上降低了对User Story制定上的要求。同时在每个Sprint结束的时候根据Sprint完成情况结合里程碑的目标对User Story进行修正。听起来似乎和上个方式大同小异，但执行过程中可以省略对Sprint筛选和组合的过程，可以说目标更加明确，对尝试达成这个目标的团队来说也相对轻松一些。
　　无论采取什么样的方式，对于进度的管理上都是需要按照传统的方式划分里程碑。这可以方便我们把握项目整体进度,防止由于Sprint过多并且更改过快以至对项目整体进度没有概念。每个里程碑就像一扇扇保险门，明确里程碑所要达到的目的以后就不再轻易变更，严格控制好里程碑中间Sprint的变更范围。从某种意义上讲，这种互相结合的方式能够有效降低项目中期由于变更过多而造成进度失控的风险。
　　这个阶段的Scrum团队的组建也不同于项目前期。这时一个Scrum团队是一个包含程序，美术，策划乃至市场人员的复合小组。这个阶段中的Sprint的之间的变更乃至小组成员的身份的变化也会更加复杂。同一个Sprint中一个User Story的执行者可能是另一个User Story的Customer，需要在开发过程中保持高效的沟通。小组成员也并不是固定不变，在一个Sprint结束之后根据下个Sprint的目标可能组合成不同的小组。比如这2周做NPC交易的小组成员，可能下个Sprint会和其他人组成摆摊系统的Scrum小组。重要的是我们作为一个整体的团队如何达成每个Sprint的目标，而不是保持单个Scrum小组的独立性，毕竟灵活性也是Scrum的一大优势。
　　这是一个频繁迭代的阶段，也是游戏内容不断增加和修正的过程，在每个Sprint结束的时候，我们都应该得到一个可以运行的版本用于衡量该Sprint的目标是否达到。策划要在每个Sprint review之后总结更正自己的设计，美术也随着一个个Sprint的完成，看到自己的作品一批批导入到游戏中的效果。所有这些都需要建立在团队成员之间高效的沟通，以及默契的合作之上。这也对团队的自我管理能力也提出考验。
　　在项目中后期，我们会面对成批从QA部门反馈的bug以及为配合市场活动而临时增加的开发需求。Scrum的灵活性在这个时候可以得到进一步的发挥，随着投入资源的增多，我们可以对这些工作内容建立单独的Scrum团队，用于解决这些琐碎但庞大的新增需求。别忘了，Scrum是最善于解决目标相对明确的短周期需求。
　　随着Sprint的一个个进行，里程碑的一个个完成，我们终于走到项目交付和维护的时候，这个时候我们面对的是单机游戏不曾经历的维护和运营阶段。
　　项目后期
　　一个MMO的开发并不随着产品发行的结束而结束，无休止的维护和资料片的推出是团队必须要面对的现实。同时团队人员的更迭也需要在这个时候开始进行。我们慢慢要把原来开发团队的部分人员抽离出来，以便于开始新的项目。对现有项目的维护和对新加入人员的培训是我们在项目后期需要面对的主要问题。
　　项目后期的工作，笔者看来分为两大类，一是原有系统的BUG，运营商的2次开发需求以及来自于市场或者策划方面的活动需求，二是并行的资料片开发。先说资料片开发，开发量和内容都基本上相当于项目中期的一个或两个里程碑，对于Scrum的处理方式可以按照项目开发中期的方式通过复合的Scrum团队来处理。通常会在版本控制系统中建立一个平行的分支进行开发，值得注意的是需要随时准备集成对原有版本的改动。对于第一类问题，则通常不会涉及太多原有系统的改动，可以单独建立程序或者美术+程序的Scrum小组进行有针对性的开发。通常这个时候，进度已经不会再成为压力，对积累了开发阶段Scrum经验的团队来说，不会有太大问题。值得一说的是如果不是自主营运，对来自运营方的需求如果要对方来适应Scrum的开发模式可能有点强人所难。好消息是来自运营方的需求并不会像我们可爱的策划案一样频繁变更。Scrum小组定义好一个接口人以后可以仍然按照自己习惯的方式进行开发，把哪些恼人的外部沟通工作扔给接口人吧，这样可以在一定程度上降低我们沟通的成本。
　　Scrum的过程控制工具
　　在使用Scrum的过程中，尤其是周期比较长的项目，对于负责项目进度控制的人来说，整体进度把握和对基础架构工作的控制都是比较头痛的问题。这时，有许多工具可以帮助我们对目前的风险和进度有一个清楚的认知。
　　可交付物件列表（Deliverable Check List）
　　不同于其他采取Scrum方式进行开发的软件项目，MMO的开发过程中，文档还是扮演着相当重要的角色。一个MMO可能产生上万甚至百万字的文档工作量，我们既需要保证开发的高速和灵活，也要保证这些文档的创建和维护。在项目的各个阶段我们需要有一个或者多个可交付物件列表。这个列表可以方便我们跟踪策划案，美术工作量，以及诸多程序设计的文档的制作情况。
　　列表中的每一项都是一个可提交的物件，每个物件都需要设定相关的负责人，审批人以及预计完成时间。这种列表是传统开发方式的产物，然后在Scrum进行的过程中，这些物件可以作为一个个User Story分布在各个阶段的Sprint中，也可以独立在Scrum之外。通常这些文档可以作为某个阶段结束的标志，然后再以这些文档为基础来做下个Sprint的Planning。通过维护这样的一个列表，我们可以对一定范围内的整体工作量有所控制，能够弥补原本Scrum在这点上的不足。
　　每天编译 （Daily Build）
　　存在着多个并行的Scrum小组就意味着会可能同时存在多个不同的版本。前面建议大家在Scrum过程中尽量将不同Scrum小组目标的耦合度降低正是为了减少系统集成的时间。有不少团队采取分头开发，然后在一个约定的时间统一进行系统集成的办法。然而笔者并不建议采用这种方式，主要原因是随着分头开发的持续，各个小组之间并不清楚对方在做什么，代码上产生的差异会累积下来。等到做系统集成的时候，有时候会被迫面对二者只能取其一或者又要花费大量的时间来修改已经完成的系统的尴尬情况。这个时候，建立一套每天自动编译最新版本的系统可以帮助你化解这个方面的危机。
　　这个系统每天会从版本控制系统中更新最新的代码来编译一个可运行的版本，并自动做一些简单的系统测试工作。这里的测试工作相当简单，往往只要能保证启动程序或者连上服务器端这样的基本功能。当编译出错或者系统测试无法通过的时候，该系统能够通知相关人员，从而迫使程序员在上传代码的时候做好merge工作。为了合并好代码，不同的Scrum小组之间也需要经常沟通，以了解对方的工作进展，帮助程序员养成符合Scrum精神的工作习惯。
　　向下燃烧进度表（Burn down Chart）
　　对于Sprint与Sprint之间，乃至里程碑与里程碑之间的完成情况，通过Burn down chart这个工具我们可以随时了解任务的完成情况以及和计划的偏差。同时Burn down chart也能很好的反映在项目进行过程之中，user story的变更情况。
　　拿下面的一个burn down chart来说。
　　这是一个持续了3周的sprint，反应的是在这个sprint过程中所有任务每天的完成情况。这里每天的完成百分比是由从第二天在每日起立会议以后收集到的任务完成情况决定的。我们可以看到在4-28和5-2这两天的计划曲线有一个起伏，这是由于当天有新增加的任务，这对我们Sprint review的时候评估这个Sprint的完成情况可以起到参考作用。
　　其他的比如告示板，索引卡，Sprint Planning等工具和方法，一般的Scrum的书籍都有介绍，笔者在这里就不再一一列举。笔者主要列举的是基于MMO的Scrum开发过程各个层面上的简单进度控制工具，以帮助团队及早发现风险，并得出应对之策。
　　推广Scrum过程中要注意的问题
　　向一个已经有过开发经验团队推广Scrum的方式并不是一件轻松的事情。没注意好的话，往往最后流于形势，不仅团队的积极性没有调动起来，甚至会让人产生反感。
　　环境的营造
　　使用一个类似Scrum这样自组织式的开发方式的时候，需要特别注意的是对于整个Scrum环境的营造。尤其不要流于形式，不然就真的是费力不讨好的事情了。笔者遇到的一个很典型的例子是：Sprint Review之前，程序的版本并没有集成编译过。于是为了准备Review中需要演示的东西，花了大半天的时间来合并代码并修改，演示结果可想一般。更糟糕的是，在user story被否决了以后，团队的积极性受到打击，对Scrum也颇有微词。
　　让团队真正理解什么是Scrum并不是简单跟大家宣读一下章程这么简单。持续的培训和心得交流是一个比较好的办法，有助于让团队了解每一步的意义和目的。同时还要鼓励大家多沟通交流，在Planning的时候提出自己的想法，多了解同伴的工作情况。不能再像原来一样各家自扫门前雪。
　　团队适应能力
　　谈团队素质是一个比较尴尬的问题，中国的游戏业毕竟还非常年轻。笔者的一个朋友曾经跟笔者抱怨过，原来尝试过Scrum方法，但试行了半年之后就放弃了。理由是Scrum太讲究团队的自我管理能力，他的团队并不能很好的适应这种自我管理的方式，而他的团队中还不乏有多年经验的开发人员。笔者的观点则是团队的适应能力跟团队成员的态度有关。我们当然不能苛求所有的团队成员都有多年的开放经验，尤其是项目失败经验，以便于他们理解Scrum可以帮他们解决多少他们曾经遇到过的问题。同样，就算有多年经验，抱着原来的方式不放，觉得这些新东西只是花招式，还不如自己的老三套来得实在也要不得。
　　团队是否能很好的适应Scrum方法，跟团队是否抱着积极开明的学习的态度有关。这在一定程度上也是依赖于团队内部的环境建设。而团队成员中参差不齐的素质笔者认为并不是太大的问题，我们并不需要所有人都能够对任务的规划和分解深刻把握，团队成员在这个高度强调沟通的环境中反而成长会更为迅速。
　　多次交付VS多次迭代
　　多次迭代并不等于多次交付，这是Scrum常有的一个误区。在每个Sprint开始的时候，我们都必须要明确这个Sprint结束的时候我们需要Review的是哪些东西。很多时候，如果一个Scrum开展不是很顺利，在Sprint Review的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了。”或者是“这个部分与另一个系统相关，我代码已经写好了，但我要一起改好了你才可以看到。”如果放任的话，这些理由到后期会泛滥成灾。我们所能做的，除了拒绝通过这些相关的User Story之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint Review上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的功能增加。
　　有些时候这也取决于我们的User Story是否范围太大太空以至于无法实现。这也对要求我们提出更具体可实现的User Story，否则就需要及时拒绝它或者再细化。
　　是否结队编程这个问题，笔者是持保留意见的。曾经有过一段不太愉快的结队经历，虽然不是随时“面向显示器编程”但相当时候两个人坐在一起写一段代码是常有的事情。个人认为在两人没有达到足够默契的程度的话，还是不要轻易尝试结队开发。而对于Scrum来说，除了结队，也可以通过buddy check（在提交代码前交由另一人检查提交）来确保互相对工作情况的了解。同时前面提到的每天Merge同伴的代码也是一个帮助团队成员互相了解工作情况的好机会。
　　Scrum毕竟是个新东东，大家还正从适应中慢慢了解和熟悉。但从笔者看来，它的确是目前最适合游戏开发的方法论之一。除了能够从容应对需求的变化之外，他鼓励沟通的方式也能一定程度上激发团队的创造力，促进团队内气氛。在面对中国式MMO的开发上，灵活的把Scrum和传统方式相结合，通过不同的工具进行控制，能很好的弥补原来Scrum对长期进度缺乏控制，以及文档管理缺失的一些劣势，从而发挥其在需求管理，针对性解决问题上的优势，更好的解决我们在开发过程中可能会遇到的问题。
相关新闻：
相关专题：
<button style="border:2px solid #background-color:#margin-right:10" onclick='javascript:var _title=document.var _url=document.location.if( document.all ) {var _text=_title+" - "+ _clipboardData.setData("Text",_text);this.innerHTML="已经复制成功，请用 Ctrl+V 粘贴";}'>复制本文地址推荐给朋友
收藏这篇文章}