Scrum与传l方式之间的不同
在用Scrum之前Q公司或者开发团队多多少已l有一些成型ƈ且大安已经?fn)惯的开发模式。打个比方说Q策划先行，然后召集大家讨论{划案，之后得出E序和美术的工作量再定义出里E碑拟订好开发计划，然后大家开始正式分头动工。在q个开发流E中Q开发h员面临的最大困难是{划案也是需求的变化量非常大Qƈ且这U变_(d)很大一部分情况可能是直到里E碑快结束的时候，大家才一h识到有些功能压根无法实现或者勉强实现的效果q不理想。这时似乎只剩下修改{划案这一条\。于是大家对于无论如何严格的审核{划案，C途L?x)以q样那样的理由变更的情况已经?fn)以为常。因为需求变更而导致品推出时间可能一推再推，以至于最后不得不砍掉一些功能才能确保品在可以接受的时间之内被推出?/p>
管传统的开发方式可能有些地方老是出问题，但大多数情况下大家也?x)比较們于下ơ注意点Q而不是尝试一套新的开发方法。在MMO的开发模式的选择上，Scrum在许多地方的可以解决传l模式所遇到的问题，比如Scrum能在拥抱变化q一点上极大的帮助开发者。类DL(fng)优点Q在Scrum的拥护派看来Q可以列出好几页来。但是，要说服一个原有的团队选择一U新的开发模式来代替大家已经熟?zhn)的方式，光列举优?gu)不够的，我们也需要直面Scrum与现有模式的其他差别Q有些甚x(chng)Scrum的劣ѝ?/p>
1Q?每次提交可运行的版本
Scrum的精髓在于拥抱变化，q强调通过频繁的交付来获得?qing)时的反馈，以便于尽可能快的调整不合理的需求。但对于某些大型MMO而言Q比如MMORPGQ系l的复杂度往往出我们的想象。如果没有一Ƒַl用过的引擎，光是前期对低层技术的开发就是一个O长的q程Q如果采取Scrum的方式，要求每一段旉提供一个可q行的版本无疑是一个噩梦。而对于同时进行的{划案的撰写Q要求提供一个反应策划内容的版本更是困难。Scrum在这个阶D如何开展，是需要克服的一个问题?/p>
2Q?Sprint的划?/strong>
相对于传l的Z里程的开发，Scrum要求划分Z个个相对较短的Sprint。ƈ且每个Sprint需要有可以提交的版本，以及(qing)一个比较明的可以体验的目标。而在MMO的开发中许多工作Q比如系l架构设计，数据库设计，术概念讨论{都很难在Sprint中体现出来，也就无法通过Sprint Review的Ş式获得反馈。但是这些东西又跟所有的人的工作息息相关。Scrum如何在能够保持紧密沟通的同时Q对cM的相对独立的部分也照֑全？
3Q?Scrum的管?/strong>
Scrum是一个强调自我管理的开发方式。无论是Stand Up Meetingq是Sprint Planning的时候都要求干涉多聆听。对于项目经理来_(d)某些时候参与感很差QL好像找不到自己在团队中合适的位置。但是项目经理又不得不对q度负责Q面对各个ƈ行的组Q每天都可能有大量新的task提出Q又有大量task被否冻I如果你这个时候去问项目经?#8220;我们到底能不能按时完成，如果推迟Q那q需要多?#8221;q样的问题的话，他也许只能对你摇摇头。我们在使用Scrum的时候，q度理上的~失也是我们需要直接面对的问题?/p>
cM的问题，在我们推qScrum的时候可能会(x)遇到很多。ؓ(f)什么会(x)有如此的问题归纳一下，原因可能如下Q?
1Q?Scrum最早来自于软g工程Q虽然现在扩展到开发的各个斚wQ由于其自n的限制性，注定要面临许多困难。（W者曾l听说过某公司号U用Scrumq行理Q要求销售，HR部门都实行Scrum方式Q很难想象这是一U怎么L(fng)Scrum。）(j)
2Q?MMO开发本w结合了(jin)跨^収ͼ分布式，周期长，变动大等多个开发难题， Scrum能够很好的解决一些问题，但对需要长期规划的问题明显~Z控制力?/p>
融合Q和其光 避其?/strong>
在笔者看来，Scrum是一U优U的开发方法，许多特征的确证明?jin)它比它的前辈们更好的解决?jin)游戏开发中所遇到的诸多问题。可是，如同它的前辈一PScrumq不是游戏开发中的那颗Sliver BulletQ再ơ应征了(jin)Brooks大师所a。所q的是，我们可以使用Scrum与传l开发方?#8220;淯”式执行的办法Q根据自w情况，灉|的选择有利的方面执行，对不适应的地方进行改q，从而能最大限度的在MMO游戏的开发中发挥出Scrum的威力?/p>
W者有q在参与的一些项目中使用qScrumҎ(gu)Q同样也l历?jin)Scrum与本土MMO开发结合时候遭遇的U种尬。笔者认为，Scrum对于MMO游戏的开发，有其利也有其弊，对于整体q度的把握以?qing)对于文档工作的控制Scrum做得q不是十分到位。对于Q何一U开发方法论而言Q执行团队都需要从自n实际的条件出发，选择性的使用。最怕的是盲目执行，暴力式地推行Q而其他Y件的工作却不跟上Q执行的团队q不明其所以，最后可能搞得h敏捷而色变，p|当然是一个必然的l果。笔者始l认为，工具Q方法始l是ȝQ如何用才是真正出学问的地方，只有从自己实际出发，冷静(rn)分析Q在合适的地方用合适的工具Q才能做到庖丁解牛，游刃有余?/p>
那么Scrum应该如何l合传统的MMO开发方式呢Q我们从目开发的各个阶段来一一分析Q如何让Scrum发挥自己的威力?/p>
目前期
目前期我们面(f)的问题有哪些Q首先是产品未成型Q团队也许对要制作的品ƈ没有一个十分清晰的概念Q更谈不上对目规模的预估。其ơ有一大堆技术性的N摆在团队面前。这些难题能否解冻I如何解决Q都势必?x)对{划案的成型有决定性的影响。这个时候，我们可以分两头采取不同的开发模式?/p>
对于面对的技术难题，q个时候目标明，团队规模较小。比较适合采用Scrum的Ş式一一dq些问题。我们可以把大家公认?x)遇到的N列D出来Q通过Scrum Planning的Ş式分解成一个个User Story再划定各个问题的优先U和互相的依赖关p，然后分别l徏Scrum团队。这个时候的目标很明，卛_到这些难题的解决Ҏ(gu)。我们希望在q个阶段l束的时候，E序Ҏ(gu)要面对的技术问题心(j)中有敎ͼ{划也对哪些能做哪些不能做有一个清楚的认识。同时我们还希望对一些我们必要克服的东西，在这个阶D已l能产生一些行之有效的工作程?/p>
对于Scrum组的组建，q个阶段我们可以以程序ؓ(f)主，{划和美术作为某些User Story的CustomerQ负责对E序工作成果的审查。ؓ(f)避免q早的陷入需求更改的陷阱Q这个时候策划除?jin)验收成果之外，不应q多的干涉程序实现的Ҏ(gu)Q而仅仅在设计User Story的时候提?gu)q意见Q事实上很多User Story应该q划和术直接提出Q。在Sprint的划分上Q我们可以以2?周的标准划分。尽量将q个阶段控制??个Sprint之内Q这取决于团队的大小和技术基Q。对于一些经q验证存在困隄User Story可以在每个Sprint Reviewl束后的Planning Meeting上经大家讨论做少许更改，让下一个Sprint向更接近我们的目标（切实可行的解x(chng)案）(j)的方向上前进。对于Scrum的范_(d)W者徏议尽量不涉及(qing)高耦合的工作，涉?qing)多个方面的User Story拆分成相对独立的部分再分头进行。D个例子来_(d)可以服务器端和客户端的技术难题分开q行Q对于涉?qing)服务器端和客户端交互的功能再单独提出来作?f)一个ScrumQ尽量保证工作的_度比较?yu)，减少互相依赖的关pR我们的首要目标是证明技术可行性，q对整个程的开展有一定的好处?/p>
对于{划案以?qing)美术风格的概念设计Q这个时候则采取较ؓ(f)传统的方式，q划和术师内部生。策划在对程序的Scrum组提出User Story的同时即提出?jin)自q疑问Q在E序执行Sprint的过E中获得对自己提出问题的反馈Q进而决定自q{划案如何撰写。美术则在这个时候确定美术风|以及(qing)在与E序Scrum组合作的过E中定某些术工作的工作流E。笔者不q个时候就加入E序对策划案q行讨论Q这也许和某些团队采取的方式不同。这U方式对{划和美术的要求较高Q既需要向E序的Scrum组提出User StoryQƈ从审查中获得反馈Q也需要保持设计工作的相对独立Q做好策划案的前期工作。这需要策划或术在前期就对中期可能发生的问题有所预见Q向E序有针Ҏ(gu)的提出需要测试的地方而不是等待程序来告诉你不可行。如果这个时候能有富有经验的产品l理或者制作h来负责这两方面的协调工作Q也是一个确保这个过E可以顺利进行的有效因素。对于程序美术在前期加入讨论，W者是持保留意见的。比如曾l经历过的一个项目就因ؓ(f)太早ȝ{划案以至于术和程序花?jin)几天来讨论每个UI元素的具体坐标是多少Q但最后却不得不尴的面(f)因ؓ(f)用户体验不友好而更改UIҎ(gu)的情c(din)?/p>
在这个阶D늻束的时候，我们应该得到一个策划案的初E，L(fng)完成?jin)整个系l以?qing)世界的架构Q可以估计出目来在程序，术和策划工作上的规模。还应该有几套行之有效的工作程Q能Ҏ(gu)目的预计规模估计出要投入的h力和目需要进行的旉Q以便于之后的市(jng)场等多项工作的计划和开展。接着Q我们就便可以投入更多资源进入正式开发的阶段?/p>
目中期
在MMO目中期Q我们面对的主要问题是对整体q度的把握，保能按时推出我们需要的版本。其中面临最主要的难题就是对需求变更的控制。这个方面Scrum有其军_性的优势Q但如何在高度拥抱变化的同时又不失对q度的把握是Scrum在这个阶D|要面临的问题。笔者徏议这个时候需要根据团队对Scrum的熟(zhn)程度来选择不同的解军_法，分别采取以Scrum方式Zgl方式ؓ(f)辅的方式Q或者反之?/p>
对于一个熟(zhn)Scrum的团队而言Q笔者的是在正式开发之前，整个团队坐在一P讨论{划案。将{划案中划分的各U系l分解ؓ(f)不同阶段的User StoryQ再通过团队之间的讨Z?qing)各l之间的工作配合需要制定出优先U。现在我们有?jin)一大堆q划案分解出来的User StoryQ这些User Story有一定的依赖关系和不同的优先U，q时候根据我们的需要将q些User Storyl合成不同的SprintQ再视这些Sprint的目标和内容l合成不同组合，每个l合我们可以视之Z个里E碑。如果你的项目的旉预算非常有限Q你可能?x)們于将一些不是很重要但如果不完成其他部门无法开展工作的User Story先行制作Q如果你的时间充裕，你则可能更們于先有一个完备的pȝ设计以及(qing)一个方便扩充的灉|架构Q让其他部门暂时{待或者做其他的事情。MQ这一切取决于目具体的需要和团队资源Qƈ没有孰是孰非之分?/p>
由User Story来构建里E碑q对团队的Scrum能力而言是一个考验Q需要团队对User Story乃至Sprint的划分有一定经验，q且能够预见整个q程中可能面临的风险。选择合适，制定好的Q可实现的User Story可以规避很多׃后期Sprint变更时候带来的q锁反应。这也是Z么笔者徏议有一定Scruml验的团队选用该方法的原因?/p>
对于初次试Scrum的团队，可以试采取相对保守的方法。通过传统的方式对{划案进行技术评估后Q划分出里程，然后Ҏ(gu)每个里程的目标制定User StoryQ再划分Sprint。这在一定程度上降低?jin)对User Story制定上的要求。同时在每个Sprintl束的时候根据Sprint完成情况l合里程的目标对User Storyq行修正。听hg和上个方式大同小异，但执行过E中可以省略对Sprint{选和l合的过E，可以说目标更加明，对尝试达成这个目标的团队来说也相对轻松一些?/p>
无论采取什么样的方式，对于q度的管理上都是需要按照传l的方式划分里程。这可以方便我们把握目整体q度,防止׃Sprintq多q且更改q快以至寚w目整体进度没有概c(din)每个里E碑像一扇扇保险门，明确里程所要达到的目的以后׃再轻易变_(d)严格控制好里E碑中间Sprint的变更范围。从某种意义上讲Q这U互相结合的方式能够有效降低目中期׃变更q多而造成q度失控的风险?/p>
q个阶段的Scrum团队的组Z不同于项目前期。这时一个Scrum团队是一个包含程序，术Q策划乃臛_(jng)Zh员的复合组。这个阶D中的Sprint的之间的变更乃至组成员的n份的变化也会(x)更加复杂。同一个Sprint中一个User Story的执行者可能是另一个User Story的CustomerQ需要在开发过E中保持高效的沟通。小l成员(sh)q不是固定不变，在一个Sprintl束之后Ҏ(gu)下个Sprint的目标可能组合成不同的小l。比如这2周做NPC交易的小l成员，可能下个Sprint?x)和其他人组成摆摊系l的Scrum组。重要的是我们作Z个整体的团队如何达成每个Sprint的目标，而不是保持单个Scrum组的独立性，毕竟灉|性也是Scrum的一大优ѝ?/p>
q是一个频JP代的阶段Q也是游戏内容不断增加和修正的过E，在每个Sprintl束的时候，我们都应该得C个可以运行的版本用于衡量该Sprint的目标是否达到。策划要在每个Sprint review之后ȝ更正自己的设计，术也随着一个个Sprint的完成，看到自己的作品一Ҏ(gu)导入到游戏中的效果。所有这些都需要徏立在团队成员?sh)间高效的沟通，以及(qing)默契的合作之上。这也对团队的自我管理能力也提出考验?/p>
在项目中后期Q我们会(x)面对成批从QA部门反馈的bug以及(qing)为配合市(jng)场活动而(f)时增加的开发需求。Scrum的灵zL在q个时候可以得到进一步的发挥Q随着投入资源的增多，我们可以对这些工作内容徏立单独的Scrum团队Q用于解册些琐但庞大的新增需求。别忘(sh)(jin)QScrum是最善于解决目标相对明确的短周期需求?/p>
随着Sprint的一个个q行Q里E碑的一个个完成Q我们终于走到项目交付和l护的时候，q个时候我们面对的是单机游戏不曄历的l护和运营阶Dc(din)?/p>
目后期
一个MMO的开发ƈ不随着产品发行的结束而结束，无休止的l护和资料片的推出是团队必须要面对的现实。同时团队h员的更P也需要在q个时候开始进行。我们慢慢要把原来开发团队的部分人员抽离出来Q以便于开始新的项目。对现有目的维护和Ҏ(gu)加入人员的培训是我们在项目后期需要面对的主要问题?/p>
目后期的工作，W者看来分Z大类Q一是原有系l的BUGQ运营商?ơ开发需求以?qing)来自于市(jng)场或者策划方面的zd需求，二是q行的资料片开发。先说资料片开发，开发量和内定w基本上相当于目中期的一个或两个里程，对于Scrum的处理方式可以按照项目开发中期的方式通过复合的Scrum团队来处理。通常?x)在版本控制pȝ中徏立一个^行的分支q行开发，值得注意的是需要随时准备集成对原有版本的改动。对于第一c问题，则通常不会(x)涉及(qing)太多原有pȝ的改动，可以单独建立E序或者美?E序的Scrum组q行有针Ҏ(gu)的开发。通常q个时候，q度已经不会(x)再成为压力，对积累了(jin)开发阶DScruml验的团队来_(d)不会(x)有太大问题。值得一说的是如果不是自主营q，Ҏ(gu)自运营方的需求如果要Ҏ(gu)来适应Scrum的开发模式可能有点强人所难。好消息是来自运营方的需求ƈ不会(x)像我们可q{划案一样频J变更。Scrum组定义好一个接口h以后可以仍然按照自己?fn)惯的方式进行开发，把哪些恼人的外部沟通工作扔l接口h吧，q样可以在一定程度上降低我们沟通的成本?/p>
Scrum的过E控制工?/strong>
在用Scrum的过E中Q尤其是周期比较长的目Q对于负责项目进度控制的人来_(d)整体q度把握和对基础架构工作的控刉是比较头痛的问题。这Ӟ有许多工具可以帮助我们对目前的风险和q度有一个清楚的认知?/p>
可交付物件列表（Deliverable Check ListQ?/strong>
不同于其他采取Scrum方式q行开发的软g目QMMO的开发过E中Q文档还是扮演着相当重要的角艌Ӏ一个MMO可能产生上万甚至百万字的文档工作量，我们既需要保证开发的高速和灉|Q也要保证这些文档的创徏和维护。在目的各个阶D|们需要有一个或者多个可交付物g列表。这个列表可以方便我们跟t策划案Q美术工作量Q以?qing)诸多程序设计的文档的制作情c(din)?/p>
列表中的每一w是一个可提交的物Ӟ每个物g都需要设定相关的负责人，审批Z?qing)预计完成时间。这U列表是传统开发方式的产物Q然后在Scrumq行的过E中Q这些物件可以作Z个个User Story分布在各个阶D늚Sprint中，也可以独立在Scrum之外。通常q些文档可以作ؓ(f)某个阶段l束的标志，然后再以q些文档为基来做下个Sprint的Planning。通过l护q样的一个列表，我们可以对一定范围内的整体工作量有所控制Q能够I补原本Scrum在这点上的不?/p>
每天~译 QDaily BuildQ?/strong>
存在着多个q行的Scrum组意味着?x)可能同时存在多个不同的版本。前面徏议大家在Scrumq程中尽量将不同Scrum组目标的耦合度降低正是ؓ(f)?jin)减系l集成的旉。有不少团队采取分头开发，然后在一个约定的旉l一q行pȝ集成的办法。然而笔者ƈ不徏议采用这U方式，主要原因是随着分头开发的持箋(hu)Q各个小l之间ƈ不清楚对方在做什么，代码上生的差异?x)篏U下来。等到做pȝ集成的时候，有时候会(x)被迫面对二者只能取其一或者又要花费大量的旉来修改已l完成的pȝ的尴情c(din)这个时候，建立一套每天自动编译最新版本的pȝ可以帮助你化解这个方面的危机?/p>
q个pȝ每天?x)从版本控制pȝ中更新最新的代码来编译一个可q行的版本，q自动做一些简单的pȝ试工作。这里的试工作相当单，往往只要能保证启动程序或者连上服务器端这L(fng)基本功能。当~译出错或者系l测试无法通过的时候，该系l能够通知相关人员Q从而迫使程序员在上传代码的时候做好merge工作。ؓ(f)?jin)合q好代码Q不同的Scrum组之间也需要经常沟通，以了(jin)解对方的工作q展Q帮助程序员LW合Scrum_的工作习(fn)惯?/p>
向下燃烧q度表（Burn down ChartQ?/strong>
对于Sprint与Sprint之间Q乃至里E碑与里E碑之间的完成情况，通过Burn down chartq个工具我们可以随时?jin)解d的完成情况以?qing)和计划的偏差。同时Burn down chart也能很好的反映在目q行q程之中Quser story的变更情c(din)?/p>
拿下面的一个burn down chart来说?/p>
q是一个持l了(jin)3周的sprintQ这个表反应的是在这个sprintq程中所有Q务每天的完成情况。这里每天的完成癑ֈ比是׃W二天在每日L(fng)?x)议以后攉到的d完成情况军_的。我们可以看到在4-28?-2q两天的计划曲线有一个v伏，q是׃当天有新增加的Q务，q对我们Sprint review的时候评估这个Sprint的完成情况可以v到参考作用?/p>
其他的比如告C板Q烦(ch)引卡QSprint Planning{工具和Ҏ(gu)Q一般的Scrum的书c都有介l，W者在q里׃再一一列D。笔者主要列丄是基于MMO的Scrum开发过E各个层面上的简单进度控制工P以帮助团队及(qing)早发现风险，q得出应对之{?/p>
推广Scrumq程中要注意的问?
向一个已l有q开发经验团队推qScrum的方式ƈ不是一件轻杄事情。没注意好的话，往往最后流于Ş势，不仅团队的积极性没有调动v来，甚至?x)让Z生反感?/p>
环境的营?/strong>
使用一个类似Scrumq样自组l式的开发方式的时候，需要特别注意的是对于整个Scrum环境的营造。尤其不要流于Ş式，不然q的是费力不讨好的事情?jin)。笔者遇到的一个很典型的例子是QSprint Review之前Q程序的版本q没有集成编译过。于是ؓ(f)?jin)准备Review中需要演C的东西Q花?jin)大半天的时间来合ƈ代码q修改，演示l果可想一般。更p糕的是Q在user story被否决了(jin)以后Q团队的U极性受到打击，对Scrum也颇有微词?/p>
让团队真正理解什么是Scrumq不是简单跟大家宣读一下章E这么简单。持l的培训和心(j)得交是一个比较好的办法，有助于让团队?jin)解每一步的意义和目的。同时还要鼓励大家多沟通交，在Planning的时候提?gu)qx(chng)Q多?jin)解同伴的工作情c(din)不能再像原来一样各家自扫门前雪?/p>
团队适应能力
谈团队素质是一个比较尴的问题Q中国的游戏业毕竟还非常q轻。笔者的一个朋友曾l跟W者抱怨过Q原来尝试过ScrumҎ(gu)Q但试行?jin)半q之后就攑ּ?jin)。理由是Scrum太讲I团队的自我理能力Q他的团队ƈ不能很好的适应q种自我理的方式，而他的团队中q(sh)乏有多年l验的开发h员。笔者的观点则是团队的适应能力跟团队成员的态度有关。我们当然不能苛求所有的团队成员都有多年的开攄验，其是项目失败经验，以便于他们理解Scrum可以帮他们解军_他们曾l遇到过的问题。同Pq有多q经验，q原来的方式不放，觉得q些C西只是花招式Q还?sh)如自己的老三套来得实在也要不得?/p>
团队是否能很好的适应ScrumҎ(gu)Q跟团队是否qU极开明的学习(fn)的态度有关。这在一定程度上也是依赖于团队内部的环境。而团队成员(sh)参差不齐的素质笔者认为ƈ不是太大的问题，我们q不需要所有h都能够对d的规划和分解深刻把握Q团队成员在q个高度沟通的环境中反而成长会(x)更ؓ(f)q速?/p>
多次交付VS多次q代
多次q代q不{于多次交付Q这是Scrum常有的一个误区。在每个Sprint开始的时候，我们都必要明确q个Sprintl束的时候我们需要Review的是哪些东西。很多时候，如果一个Scrum开展不是很利Q在Sprint Review的时候我们常怼(x)听到q样的理由，“因ؓ(f)某些原因Q这个功能我没有办法展示l你Q但是这个功能是有了(jin)的，我只需要改动小一点东西就可以?jin)?#8221;或者是“q个部分与另一个系l相养I我代码已l写好了(jin)Q但我要一h好了(jin)你才可以看到?#8221;如果放Q的话Q这些理由到后期?x)泛滥成灾。我们所能做的，除了(jin)拒绝通过q些相关的User Story之外Q在每个Sprint开始的时候还应该帮助团队?jin)解到我们需要在Sprint Review上看C么东ѝ强调我们重视的是可交付的版本，而不是一个口头上的功能增加?/p>
有些时候这也取决于我们的User Story是否范围太大太空以至于无法实现。这也对要求我们提出更具体可实现的User StoryQ否则就需要及(qing)时拒l它或者再l化?/p>
l队
是否l队~程q个问题Q笔者是持保留意见的。曾l有q一D不太愉快的l队l历Q虽然不是随?#8220;面向昄器编E?#8221;但相当时候两个h坐在一起写一D代码是常有的事情。个为在两h没有辑ֈ_默契的程度的话，q是不要L试l队开发。而对于Scrum来说Q除?jin)结队，也可以通过buddy checkQ在提交代码前交由另一人检查提交）(j)来确保互相对工作情况的了(jin)解。同时前面提到的每天Merge同伴的代码也是一个帮助团队成员(sh)怺(jin)解工作情늚好机?x)?/p>
最?
Scrum毕竟是个C东，大家q正从适应中慢慢了(jin)解和熟?zhn)。但从笔者看来，它的是目前最适合游戏开发的Ҏ(gu)Z一。除?jin)能够从容应寚w求的变化之外Q他鼓励沟通的方式也能一定程度上Ȁ发团队的创造力Q促(j)q团队内气氛。在面对中国式MMO的开发上Q灵zȝ把Scrum和传l方式相l合Q通过不同的工兯行控Ӟ能很好的弥补原来Scrum寚w期进度缺乏控Ӟ以及(qing)文档理~失的一些劣势，从而发挥其在需求管理，针对性解决问题(sh)的优势，更好的解x(chng)们在开发过E中可能?x)遇到的问题?/p>
今天为项目管理部的各个PM介绍?jin)和培训了(jin)ScrumQ得C(jin)一致的认可。ƈ同意在接下来的项目中使用Scrumq行实践?br>但同时也提出?jin)一些问题需要解冻I(x)
1、如果团队中存在工Q只有一个美工的时候，工的工作量如何估算才算合理。程序不知道工要干什么、要q多天。同L(fng)工也不知道程序怎么qӀ?br>如何保证工的工作量估算的合适?br>2、一个项目存在策划、美工、程序三个不同技能的集合Q是当做一个团队、还是当做各自的团队Q还是出ȝ划，把美工和E序作ؓ(f)一个团队?br>
不过今天的目的是Z(jin)说服PM在接下来的工作中使用ScrumQ今天得目标已经辑ֈ。接着{待目实践?
]]>