我对敏捷开发的一点理解与读书体会。

自从5月8号离职之后，就一直在赋闲。

期间读了几本敏捷，XP方面的书。下面是我对它与传统软件方法的理解， 不对之处请多批评：

1。 敏捷方法，是XP，Crystal, SCRUM 方法的集合。它们最相同的一个特点，就是：多沟通，应对变化。SCRUM 我没看，貌似有“站立会议”（？） XP中是pair，与客户的交流，Crystal中也是。而传统的“瀑布方法”过于死板，没法应对软件中的变化。

2。 eXtreme Programming，我更喜欢叫它“终极编程”。因为我认为它应该是软件开发的最终解决方案了吧，如果不出现自动化的CASE工具的话。
    结对编程：大大提高工作效率（个人深切体会）
    测试驱动：催生高质量的代码和设计（个人深切体会）
    自动化集成测试：给团队带来信心。（个人深切体会）
    让客户参与：避免浪费，目标明确
    增量交付：大大提高项目成功几率
    …… 
我觉得，以上几条，都是软件开发中最佳的，最优秀的方法与习惯。

3。 新手开发软件墨守成规，老手则会对某些方法提出疑问，而高手则会根据不同的情况，选择不同的方法。也许我们不是高手，但是敏捷方法给我们提供了高手的使用的方法。想一想，TDD，持续集成测试，与客户沟通，增量交付…… 一拿在手，恐怕哪个都放不下。

心中的体会远不只上面三条，不过再说就都是细节了。下面是我的读书体会：

1。《软件工程的事实与谬论》  55个事实，10个谬论，简直太强大了。对软件工程的传统观点与错误做法进行了批判。里面的太多方法，仍然是目前项目失败的原因。

2。《测试驱动开发》 不用我说了吧？虽然自己已经TDD了近两年，但是感觉在TDD的细节上仍然不懂很多东西。将自己的TDD步骤与Kent的TDD一比，才知道哪个是对。

3。《Effective Java》 提出了很多编码的有用建议。不过由于之前对Checkstyle的深入了解，很多东西都知道了。所以只是看了其中1/3的内容。

4。《与熊共舞》 对软件工程中的风险进行管理。我对项目中的风险只是略知一二，而作者不但写出了绝大部分风险，居然还能量化！赞！强烈建议所有关心项目成败的人读它。如果烂代码需要《重构》，那么高危的项目，就需要《与熊共舞》。

5。《敏捷软件开发》 苏敬凯翻译的那本。我硬着头皮看的。-_- 如果让gigix来翻，也许这本书绝对热卖。内容不错。 作者对方法论，心理学，很有研究，本书的第0章（就是最前面那章）说的非常抽象，需要读几个字，想一想，才能有理解。除了2.3 节和第3章，其他部分翻译的都是汉字组成的英语。一本好书，可惜了。建议大家要么看E文版，要么等下一版出来。这一版都没人审校。

6。《敏捷软件开发：原则、模式与实践》 前面很少的章节就让人明白了敏捷开发。接下来是OO设计原则（有些艰深），再后面是实际的例子。最后是两个小故事，来对比敏捷开发与传统开发。非常有趣。传统开发的弊端太明显了。

7。《人月神话》 好书。绝对的。“往项目中添加人手，会让进度更加延期”“没有银弹！……有突破性的方法……只是增量交付。”

8。《Code Complete》 900多页。不过只有500页左右讲的是如何写代码。其他部分讲了软件工程，开发方法与工具等等。基本上一天就看完了。  *_*  对于代码的大部分讲解，我已经通过Checkstyle的文档而熟知了。


以上就是辞职之后看的书。嘿嘿。发点感慨。不得不说，gigix翻译的太好了。从《重构》到《Without EJB》再到《与熊共舞》，读起来非常流畅。很有味道。另外基本翻译的很好的好书：《程序员修炼之道》系列（尤其是从小工到专家那本）。《人件》没在书店找到。可惜。 反观 《敏捷软件开发》（苏敬凯翻译），一个段落读了2遍我都不知道什么意思。后来读到“一块石头扔的太远”，才猛然醒悟，这不是之前就被批判过的书吗？ 汗。看了这个书另外的收获，就是对自己的翻译水平有了很大信心！哈哈。

偶觉得“敏捷”方法的核心就是迭代，而是是快速迭代。

人才在家赋闲  太浪费了
或者你特意要休息？

实在让我受宠若惊，感谢先！

从原公司离职后，主要是迷惑和反思。

迷惑的是对职业前途。不知道应该如何发展下去。
软件开发做的越多，就越感觉传统的过程化软件工程，反而让软件开发变的困难。如果下一个工作仍然在一个开发思想落后的公司，对我自己没有好处。

反思的是，自己心中的错误的想法。我该如何改正它们？

所以，还是ThoughtWorks 是我理想的公司。我在做英语的提高。自己的阅读能力还行，就是口语一直没说过，听力也一般。所以这段时间来一直在练习。

8月以后再找工作吧。如果ThoughtWorks 进不去，我再考虑其他的。:)

到了一定阶段，停下来总结、思考是很有必要的，
我05年时也有过类似经历，最后思考出的结论是——我要加入一个优秀的团队（当然最好是敏捷的）
其实跟你现在的想法基本是一样的

也不一定就非要去TW
优秀的团队不一定已经敏捷了，比如具有专业素质、活跃的气氛、务实的工作作风等等都很重要
还有一点很重要——项目好，有些公司本身可能不怎么出类拔萃，但这不妨碍他有很好的项目、客户
你到这样的团队中去推行敏捷更有成就感，去TW好像没啥好推广的了吧 

你说的很有道理，优秀的团队是最重要的。

不过从我之前对ThoughtWorks的了解，认为它还是最好的公司之一。我会首先把简历投给它。

如果没能进去，我再投别的公司的吧。 ：）

个人认为在国内能否实现敏捷主要是个管理问题，而不是是否具备敏捷思想或采用了什么敏捷实践。敏捷这两年都快炒烂了，按说应该所有软件企业都敏捷了，但为啥放眼望去大多数开发团队还不敏捷呢，不是错在不理解概念，而是不知道如何实施。这主要是一个管理问题。
优秀的团队也是说优秀在管理上，而不是采用了哪种敏捷实践。当然大多数敏捷实践从管理的角度上看都是优秀的。

我觉得，只要做好敏捷中的两件事，就可以为项目带来很大改变：

1。 测试驱动开发，
2。 使用持续集成工具，例如 CruiseControl

可惜就我所见，愿意写Unit Test的朋友极少。也许没有试过。

在国内软件开发团队单元测试做不了的主要原因有二：
一是管理层不理解单元测试能给软件生产带来什么好处
二是软件开发团队的成员不具备写单元测试的oo能力。不是单元测试框架有什么难度，而是写出便于测试的代码需要深厚的OO功力。

上述两个问题的解决都要从管理上着手，其实主要都是说服教育的工作。
第一个是要教育决策者认识到这种单元测试的好处
第二个问题就是要教育程序员们掌握单元测试的技巧，从这里又可以引出结对之类的其他敏捷实践。这里又可以说到大家都向往的优秀团队，其实优秀的团队都是很注重学习和培训的。

关于持续集成我认为，对于一个项目而言持续集成是个一次性工作。不需要团队中所有的程序员都明白是怎么实现。相比起来做单元测试比持续集成需要投入的精力更大。