【原创】闲聊敏捷开发——SCRUM(一).docVIP

【原创】闲聊敏捷开发——SCRUM（一） [ 哈酷 ] 于:2009-06-08 22:33:26 主题帖 看了代码ABC的测试驱动开发，不免有写点东西的冲动。再不写担心被河里其他大牛抢着写掉了。来西西河那么久了，自己就这么点货色，不抖一抖过意不去。 我要声明的是，我写的东西不代表SCRUM培训，如果我说的部分内容和你接受过的SCRUM培训老师说法有差异，不用奇怪，我并不推销这个，我只谈自己的想法。培训老师讲的东西很多太抽象，培训SCRUM的时候也经常有讲师被问倒问死的情况发生。 我自己运用SCRUM进行项目管理，我相信能够回答绝大多数问题，我经常在吃饭的时候给公司员工讲SCRUM，所以养成了尽量通俗的讲解习惯，也养成了回答问题的习惯。所以大家随便回帖提问。我发现这个东西要理解透就得一问一答才行。 我不打算像SCRUM培训那样一上来先介绍SCRUM 的那些复杂的规则，那些规则会给不了解SCRUM 的同学造成一个复杂繁冗的误解，我打算通过我的理解来推导出SCRUM 的规则，以使大家理解SCRUM的规则真正的本意。 如果你对SCRUM有所耳闻，就一定会对它复杂的规则搞的很头痛，在项目实践中，人们常常会问我或者问自己以下问题： 我们为什么要这些规则？这些规则到底对项目是起推动作用还是约束作用？ 客户还会问“人类创造性的思想精华居然被规则束缚，这是好的管理方法么？”。 开发组员会问，“我们有必要开那么多会么？这些会难道不是浪费时间么？” 在我写完这个东西以后能够就回答完这些问题了。 我认为在讨论之前，必须先把项目环境假设的糟糕一点。为什么呢？因为我曾经遇到其他一些项目管理人员谈到他们SCRUM用的很顺利。但一问具体内容，他们并没有遇到恶劣的环境，在我看来很多谈不上是SCRUM的运用成功，只能说还没有遇到显示其SCRUM威力的地方而已。 那么什么是糟糕的项目环境呢？我先想到以下三个，如果你们想到更多，请跟贴，我看看SCRUM能否解决。 1， 客户的需求频繁变更 2， 项目组士气低落 3， 资金规模有限 SCRUM主要是为了解决第一个问题，如果运用得当可以顺带解决第二个问题，然后帮助你接受第三个问题。 需求变更相对于开发组的外部就是来自客户，这里客户是个泛指，如果是公司内部开发，那么策划人员就可以算作客户，反正谁提需求谁算客户。 一开始谁都不希望发生变更的，即使客户也是不希望发生的，大家都希望有个清晰的文档，按部就班做完拉倒。有时候开发组明知这是不可能的，于是他们的期待的是客户先给出一个大方向，然后在开发过程中渐渐细化这些需求。其实这里已经开始埋下隐患——由于需求并不清晰，所以对工作量的需求同样是不清晰的，之后的‘细化’极可能被演变成‘变更’。为了一个词去争论的事情多得不胜枚举，开发组认为是‘变更’，而客户能举出好几个词（polish, jump, improvement, 甚至debug也算）来夺取道德上的制高点，拒不承认‘变更’。 客户天生就是提需求的，同时对产品缺乏细节概念，更糟的是一边开发一边展开想象的翅膀自由翱翔，在翱翔的过程中产生无数灵感。甚至鼓励开发组员一起翱翔。但很快开发组员就对翱翔失去了兴趣，他们只希望谁能来把客户这个翱翔的翅膀收下来。渐渐的，开发组员对于项目管理人员‘好坏’的定义变成了谁能搞定客户的灵感就是达人，有些管理人员只能想方设法和客户套近乎，然后含沙射影的指出“您的某某提议不太可行，是否再考虑一下？”。形成这样的现象很多人认为是正常的，理由来自于那句“客户是上帝”，客户真的是上帝么？但是，为什么这个上帝对自己要的东西缺乏那么多的了解呢？这个上帝只是出钱或者代表了出钱的人而已，所以把客户捧成上帝的根源只是把钱当作上帝。 我们都知道这个客户并非真正的神，他不可能无所不知，开发组员把怨气出在这个客户的无知上其实是不对的。因为如果开发组员期待一个“很懂，很有远见”的客户出现，那么和等待“神迹”没什么两样。 对当今变化迅速的市场来说，半年的开发时间内就可能遇到竞争对手拿出新创意和新想法，于是别人的新想法也会冲击到自己正在进行的项目设计上。即使没有竞争对手的产品来影响客户的想法，客户自己随着产品的日趋成形，也会冒出‘灵感’来‘完善’和‘改进’产品，如果客户不这么做，拘泥于‘当初说好这样，所以只能这样’的约束，结果很可能是这个产品还没有上市就要被淘汰了。那么有没有预见性特别强的客户呢？当然是有的，但是这样的客户是可遇不可求的，更何况，再强的预见性也是有时限的，来个两三年的开发周期也很正常，当初哪个‘上帝’能预见到两三年后市场的变化和自己想法的变化呢？前者也许预见起来还稍微容易点，而后者是不可能预见的。 既然如此，对于开发组来说就要理解需求变更其实是常态，需求不变更反而是理想主义。 我们真正需要的不是好的客户，而是好的机制来对