粗略学习《Agile Guide》后的总结

碍于个人能力极度欠佳，所以即使我大致了解了一下何谓“Agile Guide”（敏捷开发），也不很能理解其中的软件工程思想，只能大概谈一下我的理解。

我所理解的“敏捷开发”，应该是一种特殊的、相较于传统开发方式更值得程序开发人员重视和推崇的软件工程开发方法。这种开发方法之所以能赢得更多程序开发人员、青睐，主要原因就在于，这种方式摒弃了原来up-front的设计方案，拒绝正在过时的“瀑布式开发”，而是让开发人员通过“敏捷建模”的方式，从“简单、可持续、沟通”等等多个方面入手，旨在将目标项目划分成可以独立设计和调试、但又相互联系的子项目，并进行持续集成，从而减少错误、提高效率，更快更好地构建目标工程。而同时，“敏捷建模”是允许客户以项目开发的成员的身份，参与到项目实现的过程中的，如此一来，程序的直接开发人员便能在不断地优化程序的过程中，更好地满足客户的需求；另外的，客户参与到子项目的测试中，有利于检验子程序是否符合自己的需求，并让程序开发人员及时地重构程序，避免在集成项目的过程中，因为个别项目的失败导致主要项目的失败。这实际上是一个迭代过程，如此一来能真正提高工程实现的效率！

就该文章的叙述而言，我并不是很好地理解了“敏捷开发”的核心，所以我便直接在网上搜索了部分资料，了解到“敏捷开发”及对应的“敏捷建模”都有其对应的核心价值，包括“沟通、简单、反馈、勇气、谦逊”，其中前四点也是“极限编程”（XP）的核心价值观。虽然字面上有些抽象，但其实不难理解。这几点正好就反映了“敏捷开发”的开发特色，即：主张统一，使用统一的编码库和编程规范，便于程序开发人员沟通交流；主张简单，以最简单的设计方式实现分割的独立的子程序，并在融合了客户需求的基础上不断集成，在持续集成的过程中，开发人员根据客户的要求和设计人员的设计，快速地高效率地不断地构建或者重构项目，从而以最高效的方式实现目标工程；而这个目标工程是抛弃了一切不必要的设计的，因为“简单”原则要求如此；同时这又是一个可持续优化地项目，开发人员将根据设计者的要求进一步完善工程。

另外，关于“设计已死”的命题，原文作者也说了，这并不是正确的。虽然“敏捷开发”在某种程度上是拒绝在工程实现开始便对工程的每个步骤进行详尽的筹划和设计，因为正如文章所说，预先考虑的问题并不能保证全面，如此设计，可能导致在实现工程的过程中，不断遇到新的问题，不断进行调试，从而导致工程越来越复杂；但实际上，“敏捷开发”并不意味这放弃设计，也就是说，所谓的“敏捷开发”与UML等设计技术是不相互排斥的，只是使用的方式有所不同罢了。“敏捷开发”采取了Planned Design的方法，由设计者自行设计、再由程序实现人员实现程序。而对于每个单元，有其自己的单元设计，在“敏捷开发”的过程中，不同单元的设计都能最终聚合在一起，从而最终实现工程！

在查阅资料的过程中，我看到，原来结对编程也是“敏捷开发”的一个阶段。通过结对编程，开发人员在同一台机子上进行程序编写，这样便能在写的同时又另一人监视，降低出错的概率。想来我和我的结对伙伴在编程时，倒也没有发现这其中的用处，只是相互商量，相互检查而已。不过，在以后的团队工作中，我们可以按照分配好的任务，各自完成自己的任务，从而更好地实现我们的工程！我们的团队成员已经按照一定的规则分配了相应的任务，接下来，我们便要好好地利用“敏捷开发”的方式，进行我们的程序设计。我们会争取让设计成员提前对我们的任务进行一定的简单设计，然后再有编程经理带领编程人员进行开发；另外，作为软件工程学习的一部分，我们团队虽然是开发人员，但也可以把自己定位为客户，由此去进行程序的优化和深层设计，这样就相当于让客户也参与到程序开发中了！如此一来，便能更好地提高我们团队的工作效率！

还有，我还了解到有一种类似的迭代式增量软件开发过程管理方法，称为Scrum。这也是可用于管理软件开发项目的。所以我们团队也肯能有所参考和学习，这将由我们讨论研究后再下定论！

以上，是11061169林谋武同学粗略学习“敏捷开发”的心得。