以人为本

　　在Fowler的《新方法论》中，Fowler认为敏捷重要的两个特性之一是以人为本，而非以过程为本。如果听到下列言论，我觉得意味着你的组织文化可能不是以人为本的：

　　1、随便找几个人进行简单的培训（这些人只使用过VB开发过课堂作业程序），可以很好的编程了

　　2、制定一个执行步骤规范，人手一本，只要按照上面一步步操作可以了

　　3、谁离开了，马上找一个人来可以来替换他的工作。

　　我觉得这已经表明老板认为程序员只不过是生产线上可替换的零件了。

　　我觉得不以人为本的团队，也体现了对于如下几个价值观的不认同：

　　1、信任。程序员不值得信任，并不是像Fowler所说的程序员是担负责任的专家。

　　2、沟通和反馈。虽然通常他们会强调沟通的重要性，但是他们很少强调反馈的重要性。他们所谓的沟通是单向的下命令，而非交互式的。

　　3、尊重。团队中其他人的工作是不值得尊重的，架构师可以有一万个理由瞧不起编写代码的程序员，在这样的团队中，架构师通常都是不参与编程的。

　　迭代，小步前进

　　我非常喜欢Kent那个开车的比喻，可是领导认为每天总结（站立式会议）或者每隔一段时间进行总结都是没有必要的。

　　设立短小的、可控的计划是无用的。

　　还有一个根本的

　　我觉得敏捷开发根本的一个观念是实事求是，也是Kent在《解析极限编程》中所说的，XP是将有益的事情做到。所以敏捷方法都是一堆实践原则的集合。

　　Johnson讲的循证框架也是在强调这点。我们可以笼统的说自己在实践敏捷开发，或许不是那么纯粹的XP，Kent的说法也是建议循序渐进的使用XP，但是觉得有用，可以解决你遇到的问题，又不会有很大的副作用，那么把它引进来，即使这个方法是CMMI阵营的。

　　我认为每件事都要经过科学的论证，而不是猜测，可是这一点也得不到认同。

　　敏捷叫停

　　我们的团队请了一个日企的强调使用V模型，严格文档驱动的顾问，意味着我们的敏捷之旅结束了。

　　我想我们之所以没有沿着敏捷的道路走下去，并不是因为实践的问题，也不是因为原则的问题，而是价值观的问题，总结如下：

　　1、我们的老板觉得程序员是可替换的零件

　　2、质量不重要

　　3、开会是下达命令

　　4、简单是把所有的代码都写到一个文件里

　　5、对于大家不信任

　　6、个性不应该被尊重，服从命令是第一位的，海军陆战队风格

　　7、实事求是

　　Kent说，如果你的团队的价值观是与XP抵触，那么不要使用XP。

　　我觉得透过种种敏捷实践的实施不力，其背后隐藏的其实是价值观的难以统一，至少我觉得我在项目中推行敏捷，挣扎了一个半月终于要搁浅，原因在于实在难以在价值观上达成共识，困难的是难以说服老板改变观念。

　　Ps：我是研究生一年级的学生，我们的项目很大，可是人不多，我觉得非常适合使用XP。我认为XP是非常好的天才的想法，可以解决很多问题，可是来给我们做指导的那个日企的人说在大公司做大项目都是要听话的，不会用敏捷之类的新方法。可是我看到的那些软件开发大师的书，和论坛上各位的讨论，都觉得这个方法应该是经过很多大型项目的验证了，可是我们导师询问了几个公司里的人，却都没有用过，他们也觉得TDD很好，但是是没用过。

　　我是作为我们团队的技术主管，其实是矬子里面拔大个，但是这是我接触敏捷1年来，并且在这个项目前期时使用敏捷的想法，或许我的所有观点都很幼稚，所以还请各位有工作经验的多多指点