敏捷开发感想
遇到的问题
1. 沟通
在我开始第一份正式工作的时候，带队的boss就跟我说：从现在开始你们要记住“沟通”和“需求”这两个词，这是整个项目中最重要的。就目前我所接触到的三个团队来说，沟通一直都是一个非常严重的问题，比如：策划团队开会做出一个系统功能的更改，但是并没有及时同步到程序和美术，程序和美术仍然按照之前的旧方案进行设计，等到知道需求改动时，已经做了很多无用功，于是相互指责、埋怨，这就是项目失败的开始。这可能只是一个特殊的例子，但是我们不能忽视的就是，沟通是否及时有效，决定着一个团队能否高效的运作。
鉴于我目前所在的团队还比较小，只有4个程序，2个美术，1个策划，所以沟通不畅的问题表现的并不是很突出，但还是有所体现，主要是对于游戏的理解，以及游戏最终所呈现出来的形式。每个人都是单独的个体，对于游戏都有自己的理解，在工作的同时如果没有和其他人进行充分的沟通，就会按照自己所想去实现游戏，总结起来就是对于团队的共同目标没有清楚的认识。其实更多的是个人主动性的问题
对此我们专门在一个sprint结束时的回顾会议上讨论了这个问题，每个人都提出都游戏的看法或者不清楚的地方，集中解决。
另外一个沟通就是，现在每个人都是只关心自己做的事情，对于团队其他成员在做什么、其他的任务完成到一个怎样的程度都不清楚，对项目的进度不了解，每天早上的例会只是一个形式。我们scrum产品需求的发布采用的是便利贴，团队成员对task的关注度不够，不回去自动更新产品需求，也不会更新燃尽图，这也更多的是团队成员主动性的问题。
我希望可以找到一个可以在PC端进行管理scrum的软件，目前在尝试。
2. 敏捷的思维
很多团队虽然在进行敏捷开发，但是团队成员的思维却还是停留在很古老的阶段。有成功项目组总结经验说，一个团队完全敏捷完全成熟大概需要半年的时间。这个时间应该是团队成员个人思维转变的时间，一个新人加入一个成熟的敏捷团队可以很快适应敏捷，但是一个高水平团队从零开始敏捷开发却需要很长时间，我认为这些问题可以归结为没有敏捷的思维。
敏捷的思维是要求所有的团队成员都能够关注整个敏捷开发过程，关注项目的进度，关注个人计划于项目计划的契合，不怕犯错误，不断学习，保持迭代开发。体现最明显的地方就是看团队成员是不是时刻关注着产品backlog和task，不断对其更新，不需要PO或者master为其安排任务。
每个人都有更多的主动性，我觉得这也是一个scrum成员最基本的素质。
3. 团队成员的个人实力
这里所说的个人实力包括两个方面：技术实力和情商
每个人的技术实力都不相同，而scrum则是希望团队所有成员都能都承担比较重要的任务，这对于个人来说也是极大的提高，但这总是有一个时间过程的。团队的平均水平是由团队内水平最低的那个人来决定的，当团队实力差距较大时，应该怎样处理这个问题？可能有很多团队无法进行
scrum的原因就是团队成员实力参差不齐。在我看来，scrum是一个不断学习的过程，每一个成员都应该去用于承担重要任务，不怕犯错误，学会如何思考和解决问题。
我的解决方法就是，严格执行scrum的任务拆分和估计点数，然后按照优先级将任务进行区分，所有团队成员最多接受一个任务，然后按照优先级从高到低的顺序依次领取任务，这样，水平低的成员也可以领到重要的有难度的任务，这对于他来说是一个考验，更是一个很好的学习机会。
一旦水平较低的成员领到高难度任务，我们更希望他能够独立完成，在确实有困难的情况下，其他人在完成自己的任务之后可以适当帮助，这种帮助更多是在指导层面的。
4. 模块的划分
按照我们国内一般游戏公司的做法，会将所有人分为策划、美术、程序等，然后策划又分为系统、数值、内容、关卡、世界观等等，我不知道这样分的理由何在。我所接触的国外游戏公司关于游戏策划招聘的职位是game designer或者game producter，曾经就这两种职位咨询过zynga的主管，他解释zynga所要求的策划必须是全才，要懂产品，甚至要规划游戏的商业运营与推广，但是并没有我们严格意义上所说的各种策划。在实际工作中我也发现，各个策划并不是独立的，每个人都必须了解的更多，例如在我看来，系统和数值就是密不可分的。
Scrum所要求的就是每一个成员都要会策划、美术和程序，全面发展，不要求精通，但起码了解，并且在此基础上可以进行沟通，而不是策划完全不懂程序，程序不知道游戏为什么这么设计。
这带来的一个问题就是，我们如何拆分任务？敏捷开发要求尽量将任务拆到最小单元，那么这个最小单元是最小的一个功能点（可能会是一个需要策划、美术、程序合作的小功能）？还是拆到再详细的关于每个人的最小任务（按照每个人职能的不同，将功能拆到最细）？
我们两种方法都试过，给我感觉最好的是按照个人只能将任务拆分到最细，这样的话每个人都可以很明确的知道自己未来一段时间有哪些任务是关于自己的，而不是对于一个功能很模糊、不知道自己要参与到什么程度。
5. 适应变化的需求
我们对需求变化的心态始终是消极的，这也间接降低了我们的工作效率。敏捷开发中，一定要用积极的心态去面对变化，欢迎需求的变动，每一次变动都是将游戏变得更好。如果对需求变动有消极的抵抗心理，那么游戏就不可能完成迭代，这更多的是需要个人的心态调节。
6. 没有明确的目标
游戏开发的开始阶段，好多人都不知道这个游戏的最终形态是什么。游戏开发周期中，不知道周期结束后游戏是一个怎样的形态。这都是源于每一个阶段没有提出一个明确的目标，所有人为了敏捷而敏捷，都是抱着边走边看的心态。
所以我们一开始就应该制定里程碑，不只是画燃尽图，更要关注未来我们每一个阶段要达成什么样的目标，这对于项目推进也是有好处的
7. 透明度
Scrum是完全透明的，每个人都知道当前的项目进度，不管有好消息或者坏消息，每个团队成员也都能及时了解。但是对于我们来说，有时候会隐藏掉坏消息，或者说忽视掉比如产品的重大bug、测试不完整、产品功能被否定等，可能很多很多公司存在和我们一样的问题，甚至是国人的通病（经常看新闻联播你就知道了）。
我分析存在这个问题的主要原因是：
- 惯性思维，没有scrum透明度这个概念
- 负责人害怕担责任，没有意识到这是一个团队，这是一个整体
- 觉得坏消息会打击士气
- 不能接受批评
要做到透明，首先团队的srcum master要敢于自省，能够接受批评，每个sprint的产品发布会要邀请更多的人参与，欢迎不同的意见。对与产品要有最坏的打算，在坏消息暴露出来的时候能够及时调整。其次团队的每个成员要有拥抱坏消息的态度，而不是害怕。早一点暴露出问题总比产品上线之后暴露问题好，同时每一次有坏消息就意味着一个新的学习过程（scrum最基本的就是不犯同一个错误很多次）。一个成熟的scrum团队可以犯的错误很少，因为他们几乎已经将所有的错误都犯过了。
再次，团队的每个人都应该用于接收他人的批评，不管是团队内部还是团队外部，更多的批评意味着更多的进步，学会接受批评可以帮助自己前进一大步，所以我觉得sprint结束时的回顾会议，除了对上个sprint进行回顾意外，更多的是团队成员情感修复会议，大家可以将任何自己的意见拿出来说，将所有的问题谈开，这对于团队的相互了解和团队的凝聚力是非常有帮助的
8. 环境冲突
很多执行敏捷开发的团队，表面上是在做敏捷开发，但是实际上周围的环境却施加了层层阻力：老板对敏捷的认识，项目进度的压力，敏捷开发中遇到的种种困难。都会使敏捷开发无疾而终。对于这些只能说，挺住！如果事不可为就放弃敏捷吧
9. 没有搞懂敏捷
敏捷的目的是解决传统项目开发中的种种问题：开发进度前松后紧、项目成员拖沓、执行力低下、产品开发周期过长、不适应市场变化等。有的人对于敏捷有着更高的要求，这是不切实际的，也不是任何团队都适合敏捷开发。当你搞懂你们团队面临什么样的问题时，再看看敏捷开发可不可以解决这些问题，再决定用不用敏捷。
就像一个敏捷开发大师所言：任何人都可以进行敏捷开发，傻子也可以，只是傻子用敏捷开发出来的东西不能用而已。
敏捷开发适不适合开发
到底敏捷开发适不适合游戏开发？仁者见仁，智者见智。从我们的实践来看，敏捷开发是有很大优势的。有以下几点在敏捷开发上表现的很突出：
- 极大提高执行力
- 很好的适应需求变动
- 游戏制作周期缩短，能够快速推出产品，看市场的反应，然后再做调整
- 对团队成员的个人实力成长有很大的促进
- 自我管理能力加强
当然敏捷开发过程中还是有很多问题的，在这里只提到了一部分（关于我们实行敏捷三个月以来的问题），更多的问题可能我们没有发现，也欢迎大家前来拍砖，多提意见，谢谢