从scrum说敏捷

最近又搞了一次scrum培训，整整搞了两天，加上以前也有参加过scrum的培训，同时一直关心敏捷开发，所以有了一些想法。

首先，我的观点是软件开发是一个介于科学与艺术之间的事情。至少目前是这样。也许有一天有人把软件开发研究透彻了，搞成一套工具，一套流程，是个人都可以搞出一个成功的软件，但是，目前的情况不是这样。这个有可能就是软件的本质。

由于有了这个本质，所以很难精确的度量。可以度量，但是很难精确，这就像可以很快的说A比B漂亮，但是很难说漂亮多少。

scrum或者其他的敏捷开发方法对团队中的个人要求很多很高，其实这也是从另外一个层面反映出了人是一个很重要的因子，而且常常是最重要的。但这里也不是唯人论，工具流程的确可以帮助我们很多，但是，不要千万不要被工具流程控制。

既然人是首要因素，那么敏捷开发中的结对编程就有了商量的余地了。
一个好的或者立志于成为伟大的公司，不应该时刻想着怎么从员工身上榨取多少生产力。而是应该和员工一起可持续的发展，有张有弛。结对编程从效率上没的说，但是从社会学上，估计没有几个人支持，或者支持的人有一定的目的性（比如新人通过结对可以快速熟悉系统）。愿意一辈子处于结对工作状态的人应该不多吧，结对给人的精神压力太大，所以不是一个可持续的发展道路。

scrum可不是你想的那么简单.像LZ所说scrum注重的是团队和合作.而且对于客户对需求的变更能及时实现.
与其从一开始就文档就定好条条框框,然后沿着它细水长流的编程.编程激情都慢慢消失殆尽了.
最重要的是在编程过程中如果注入新思想,和及时满足客户需求变更的.这都不是什么可持续发展道路.
在scrum中2周或者一个月来作为一个冲刺点.在完结时特有成就感,编程也似乎带劲,有激情.

我们公司在scrum实践中遇到两个最严重的阻碍：
1. 任务因为依赖性问题老是变动优先级
2. 程序员不乐意取不熟悉的任务，任务分配时，加重了等待和依赖性问题。
请问高手有何解决方法

1 依赖性问题应该早于开发解决，有了依赖图才会有优先级。
2 这个是可以接受的，一个团队中的成员大部分应该领取自己熟悉的任务，但是，一个团队的构建中，应该放置有少数喜欢挑战的人。

资本就是榨取剩余价值，你违背不了生产规律。当预算在你的手上甚至预算从你的钱包里扣除时，你自己就知道怎么做了。

但公司不会和所有的员工一起可持续发展，保留优秀的，淘汰掉不合适的。

我这个不是违背规律，而是相反的顺应规律。这是一个短时间和长时间的问题。所以说，适合于立志做一个好的或者伟大公司的公司。

优秀的总是少数，公司的管理水平体现在如何把不合适的培养成合适的，如何把合适的培养成优秀的。当然，对于实在培养不了的，就只有淘汰了，但是，这个淘汰应该是一个负责任的淘汰，是一个尝试培养未果的淘汰。

你再向上一层就知道了。

我们用了 Topo研发管理系统，里面提供了多套模板，敏捷的，cmmi的，
正好适合不同的项目

Scrum也好，别的什么xp也好，所有的敏捷方法论要得到好的实施，要有成效，首先要解决的问题就是人的问题---怎么让所有的人觉得这个任务就是我的任务？解决不了，都是空有其表而已。

说的不错，不管什么项目，不管采用什么开发方法，目的都是把东西做好，落实到最后，具体的东西还是人来做，关键是团队的人员协调，这个东西说起来容易，做起来就难了，那就是仁者见仁，智者见智了，呵呵！