结合工具来实现敏捷开发 - 1

敏捷开发，我想概念不用多解释了，网上可以找到N多的地方。敏捷开发是跟传统的瀑布开发模型正好相反的，当然也不能说孰优孰劣了，都还有团队在用着，甚至有些公司两个都同时在用，既然还有用武的地方，也就不会说谁代替谁了。

我们公司现在都是敏捷开发，采用的是敏捷里的Scrum方法，除了Scrum，敏捷里还有很多其他开发方式，例如极限编程，需求驱动开发等等，虽然本质上都有相同点，但是具体还是有不少区别的，不过因为我们公司用的Scrum，所以我也只能讲讲Scrum了，其他的话，留个厉害的人去讲吧。

先说采用敏捷开发之前的公司情况吧，跟很多公司一样，也是用瀑布方式的，所以每个版本，一开始就定好了要做哪些功能，然后开发就吭哧吭哧在那里干，最后Commit代码，然后QA去测试，最后交给客户。一开始其实也Ok了，2000年左右的时候，客户反正也不会怎么挑理，所以日子也还好过。

但是大约2005，06年左右开始，事情开始有变化了，一方面，做我们公司同类软件公司越来越多，压力很大，使得我们需要比他们做得更好，功能实现越多；另一方面，客户越来越苛刻，一会儿希望实现这个功能，一会儿希望实现另外一个功能；还有一方面，由于全球化的协同办公越来越多，使得客户对软件的性能要求越来高。一切一切使得之前的开发模式很难再适应，往往出现了，软件开发完成后，客户认为不满足他们要求，又或者说某某软件企业有那个功能，你们怎么没有。

压力就开始变得很大了，所以一开始，上面的领导就一味得加这个功能，改那个功能，甚至为了超过竞争对手还不断加一些其实客户不断用得着的功能，最后导致开发很累，测试很累，软件质量根本就没法上去。

后来呢，大家也知道，开始出敏捷这个概念了，不过其实现在想想，敏捷真的只是一个概念，因为它没有具体的方法让你去实现，就是说让你要去不断地跟客户沟通，要迭代，要简单。但是真正要去实现它的思想，却不是很简单，往往你有时候没法下手，甚至下手后，却发现事情并非你想得那么简单，虽然做得好像有模有样的，但是团队的效率还是没变，产品的质量还是没变。

说到这个点上，就要开始说一下管理这个事情了，先不说软件，就说一个公司好了，如果没有管理，即使公司里各个都是精英，这个公司也不会发展得好的，因为一方面可能谁也不服谁，所以谁也管不了谁；另一方面，对于所做的事情，什么是对的，什么是不对的，也没人去说；甚至，今天这个人没事干，但是那个人累得要死，都没人知道。所以对外而言，就知道这个公司的人都很优秀，但是这个公司其实没业绩，死气沉沉。归功到底，没有好的管理，怎么去让正确的员工在正确的时间做正确的事情，这个是管理；怎么去让正确的员工觉得自己是待在一个正确的公司，这个也是管理。

回到软件上说这个“管理”，软件其实比公司还复杂，公司其实就是管这么几个人，但是软件呢，管的是代码，管的是逻辑，代码和逻辑都是千变万化的，没这么容易去管理的。公司的管理可以用制度，但是软件开发呢，当然制度是必须，但是也仅仅是表面的，试问，我怎么通过制度去让这个开发把这个功能给我做好呢？要知道开发人员做好的一个功能并不一定是他的水平问题，也许是设计团队没设计好，也许是客户需求没讲清楚，也许是测试人员忘测了，也许是。。。。。。我们好像没法用制度去解决这些问题，因为制度总是需要人去监督的，但是监督这个事情总是有局限性，没办法百分之一百监督到。

(未完待续)