粗略阅读《Agile Software Development》后的感想

大致配合翻译和词典阅读了一下这篇文章之后，我另外还查阅了维基百科、百度百科和MBA智库百科还有一些网络上的文章。对敏捷开发有了一个大致上的浅显的认识。

敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。

我在互联网上又查阅了一些其他的关于敏捷开发的资料，包括一些有过这样实践经验的程序员对敏捷开发的看法，还有他们用敏捷开发的办法实际上达到的效果。首先，我个人很喜欢敏捷开发的功能。我不喜欢阅读长篇的文档，和别人合作写程序的时候，如果对方给我一份很长的说明文档，那我的工作效率不会很高，还需要另外花时间去阅读文档和代码。我最喜欢敏捷开发里的一点就是面对面沟通。如果我能在程序前面对面地和我一起合作的同伴进行讨论，那么我们交流会顺利很多，效率也会高很多。敏捷开发讲究面对面沟通，这一点对小组内的效率有很大的提高。另外，敏捷开发的小组会议主张的是站立会议即强调“stand up”，既然是站立会议，那么就不会有太长的时间，这也强调了小组成员之间交流的效率。就我自身的一个例子来说，在上一次的结对编程作业中，我一开始拿着代码毫无思路，然后和同学一起面对面讨论了不多久，就明显感觉对代码有了一个比较完整的理解。不同的人在讨论的过程中，一句不经意的话有可能就会给别人刚好需要的提示。在结对编程过程中，读懂代码之后，有段时间还是对新的算法毫无头绪。在和高小洲同学讨论的过程中，我们就一起想出了更好的算法。而我们讨论的时间其实也并不长，实际上关键的也就是讨论中的那么一两句话，但是这一两句话对于整个工作的意义非常重要。之后的实现算法编写代码都很简单轻易了。

另外，敏捷开发讲究实际讲究效率，第一位的是做出能够运行的软件。我十分赞同这种讲究高效率的态度。在软件编写的过程中，其实很难去说清楚现在的进度进行到百分之多少了，有可能工作只差一点点就完成了，但是这个难关需要耗费的时间有可能比之前所有的零碎工作加起来还要长也不一定。因此只有一步一步脚踏实地，做出能够运行的软件了，才能认为是进度向前推进。一切不能运行的东西都是浮云。我很喜欢这个观点。敏捷开发本来就比较适合规模不大的团队来运用。这样的脚踏实地的观点，能够让整个队伍更加求实，减少在队伍中划水的人。让整个队伍更加有效率的运行起来。

敏捷开发讲究的重在做出可以运行的软件，进行小版本发布，不仅仅能够在组内让效率更高，整体上来说，经常有小版本发布，也能让外界对于这个软件的热情更加持久，不会出现一段时间没有更新这个软件就没有人气的状况。持续的小版本更新也能够让客户更加快地体验到软件的进行方向，让客户更好地进行反馈，让开发人员得到更多的信息，更加好地获得需求，从而让软件开发不至于走向错误的路线。

敏捷开发需要较少的文档。太多的文档很烦，我深有体会，敏捷开发强调要“较少的”文档，而重在面对面的快速高效的交流，这在前文中我已经说过我对此的看法了，因此不再多做赘述。敏捷开发的文档要少要精炼，要少但不是不要。没有文档很多工作会很难进行，因为毕竟开发人员不可能把所有相关的东西都记在脑海中，还是要进行一些记录的。但是重点是要怎样在不多的文档中把必要的事情记录下来。这一点上，我还没有过进行这类工作的经验，网络上的别人写的资料中，也基本都仅仅是提到了敏捷开发的小组的文档需要简短精干这一点，而且必要记录的东西是不能少的这几点，并没有多做陈述，因此我也只能说在今后的编程中尽量往这个方向去做去努力。

在文中，提到了“Is Design Dead?”，我认为并不能这么说。文中说敏捷开发的确不会在工程一开始就对每个步骤进行详细的设计与谋划，这是因为刚刚开始整个工程的时候，不可能把开发过程中会遇到的问题完全考虑到，那么如果在开发过程中遇到问题，就有可能被之前妄加的谋划倒入误区，导致问题复杂化。但是敏捷开发不再一开始进行详细地设计，并不是说敏捷开发要完全放弃设计。敏捷开发也会进行相应的设计，只是使用了不一样的方法而已，不会在工程一开始便谋划清楚所有事情，但是每个部分也会有设计，最终的工程会按照设计满足用户的需求，达到开发的目的。

对于我个人来说，值得一提的是，结对编程也是敏捷开发的工作小组常用的方法之一。在进行上一次的结对编程作业的时候我就明显地感受到了这个工作方法的好处。这个方法看似来两个人干一个人的活，对整体效率有降低。但是，首先，如上文说的，至少在我个人来说，我明显感受到了成员之间的讨论对于工作特别是整体思路上的好处，有些一个人冥思苦想不得解的问题，能够在两个人的讨论中很快地解决掉，而这其实就在很大程度上提高了开发效率。其次，两个人结对编程，一个人在编写代码的时候，犯下的简单错误，经常能够由另一个人很快指出，这样一来节省下来很多调试的时间。在一个人单独写程序的时候，有很多时间都用在调试上了，结对编程就能够把这些时间中的很大一部分节省下来。再次，两个人的知识面比单独一个人的知识面要广得多，有很多时候，编程过程中遇到一个问题不会，或者一个需要的技术不会，如果是一个人独立编程的话，那么我必须去查阅资料啊文档之类的，学习相关知识再来解决问题。而如果是结对编程的话，同伴能够互相高效率的解决对方不会的问题。这样能让整体进度势如破竹。结对编程是敏捷开发的常用方法之一，也是敏捷开发的思想的具体表现之一。敏捷开发的高效交流等等特点都能体现在结对编程方法上。

虽说，我个人很喜欢敏捷开发这种开发方法，但是敏捷开发也并非适用于所有情况下。我之所以觉得这个方法很好，是因为我身为一个学生，开发的软件种类、规模有限，组成的工作小组能力、人数有限。对于编写规模不大的软件的人数不多的小组，要实现面对面地高效交流、保持人员精干、保持队伍工作效率之类的都并非难事。但是如果是规模相当大的软件开发，比如说微软的windows7操作系统的开发，上千万行的代码量，成千上万的工作人员，这种规模的软件开发每次都要实现面对面的高效交流基本是不可能的。因此进行这样规模的开发，就需要在文档中，把敏捷开发中在面对面交流时说清楚的东西完全写清楚，这样虽然不比面对面交流来得效率高，但是却能够让这个大规模多人数的工作组织正确地运行起来，完成小团队无法完成的大工程。

以上观点均是我的个人观点，错误和纰漏的地方，敬请各位大神和各位老师、前辈指正。