谈敏捷，谈开发

--《Agile Software Development》读后感

北航计算机学院 110616班 11061171 毛宇

联系方式：maoyu815930@sina.com

最近拜读了一下Martin Fowler的大作《Agile Software Development》（http://martinfowler.com/agile.html）有了很多的体会，这里简单分享一下。

《方法论》

首先从方法论的角度来谈敏捷开发这个话题：首先我们要明确的一点，敏捷开发其实是一种传统“正规”工程方法的反叛。敏捷型方法是：“适应性”而非预见性，“面向人”而非“面向过程”。这里要区分的就是为什么说传统的开发方式运用于软件工程其实不具备太强的预见性和适应性，在文章中提及的是两个方面：

1.从设计角度来理解：软件工程又有一定的特殊性，就是它的设计其实也是具备了一定的不可检测性的，土木工程的设计，基于一种很成功，很经典，很有效的分析方法上，人们知道怎么样去做受力分析，怎么去模拟（比如用计算机软件等）。但是对于软件工程，很多错误都是在实践中才能够发现的，因此，采用传统工程模式来进行软件工程的运作是存在了一定的问题的。

2.从需求的角度来理解：软件的很大一个特点，就是需求的不固定性。我觉得文中说得很清楚，无疑包括了两点，一个是需求是不好获取的，其次是需求随时都在改变。因此很难实现可预见性。我清晰地记得去年的时候做一门课程大作业，最开始我和基友们都非常兴奋地讨论决定做一个格斗类游戏，但是在开发的过程中，做着做着做成打飞机的游戏了。最让人感到意外的是，做完了以后我们才反应过来原来我们最初是准备要做一个格斗类游戏的，但是在这个过程中并没有人提出这个疑惑，及时纠正。也就是说，需求与我们的实际开发啊是很容易偏差的。

另外作者还谈到，在软件自适应的过程中，迭代是一个非常有用的技巧，此外，还发展有XP极限编程，SCRUM等实用的技术。其中我对SCRUM非常有体会，SCRUM我的理解就是将一段很长的征程转化为很多个小小的“冲”，这样的好处有两点，一个是目标明确；另一个就是积极性被得到充分地调用。我觉得在我们之后的软件工程作业中，把XP和SCRUM相结合将是非常好的。

《设计已死？？》

一般来说有两种不一样的设计模式：

一种是规划性设计也就是传统的先列好计划，再执行。但是会引发的问题就是说会加剧设计者与编码者之间的矛盾，其次它的灵活性也非常差。

演进性设计很类似于code and fix,因为整个过程中要求不断地去做出即兴的决定，它的优点就是它很灵活，缺点也是非常显然的，如果设计导致bug，那么在后期将会造成难以挽回的局面。

但是总的来说，规划性的设计总是更好的，但是也会有很多问题需要去解决。作者随后提出了一点，就是XP编程可以抚平变化曲线，也就是说在设计上的修改可以相对低成本地转移到实践中。要做到这点，就必须要求XP编程有一定的设计性。而XP编程的设计性又融入了编码，所以，它其实是一种欲望（这词用得很好），一种一直迫使保持代码整洁，清晰，简洁的驱动力。

也就是说在敏捷开发中，特别是XP编程中，并不是说为了灵活而舍去了设计。只是说设计在两种不同的软工模式下有着不同的体现方式，在敏捷开发中更多地体现在一种"趋势",一种引力上，而不是一个事先列好的指导提纲。所以它的实际意义其实也非常明确了，我们在进行敏捷开发的时候，千万不要忘记设计，设计是控制我们的工程在掌控之中的一种必要的因素。只有这样，才能切实有效地实施敏捷开发。

《STANDING UP》

standing up是很有意思的一种meeting方式，一个队伍每天站在一起更新一下各自的状态，通过standing up这种方式，使得meeting尽可能的简短有效。standing up这种方式其实也和大多数meeting的目的一样，分为四个目的，我觉得非常重要，这里粘贴一下：

To help start the day well 更好的开始新的一天的工作
To support improvement 支持改进
To reinforce focus on the right things 加强对于正确事物的关注度
To reinforce the sense of team 增进团队凝聚力
To communicate what is going on 交流进展
也就是GIFT原则。

在讨论的过程中应当注意，我们应当谈论的事情是我们昨天做了什么，遇到了什么问题，以及今天准备做什么。
让我觉得非常有意思的是文中提到的关于standing up meeting 的细节，比如，通过丢硬币来决定说话的顺序；每次meeting之后要有一个ending signal；比如，在工作地点直接

meeting而不要在会议室meeting等等，其实每个细节都有它的道理。我觉得我们小组非常有必要把这种模式应用到我们的每周传统例会中。

《Using an Agile Software Process with Offshore Development》

在这篇文章当中，作者分享了他曾经参与项目所得到一些经验教训，我仔细参读了一遍，不得不说有几个建议我真的没有很好的理解，比如为什么要将团队按照功能性来划分，而非事件来划分。我在我曾经参与的几次软件项目中，都习惯于按照事情来划分，因为按照功能来划分会产生很多问题，比如分配不均匀，没有办法很好的在功能之间衔接等等。
其他的一些建议则非常有意思，比如使用wiki来搜集公共信息：使用wiki这一个非常自由的方式可以很好的帮助团队形成自己的记录结构，其次，这种记录方式很简单，容易搭建，我们团队在开发过程中也应该引入这样的方式，而不是一直使用QQ群这种方式，很低效，而且消息查找很不方便。
又比如Use Regular Builds to Get Feedback on Functionality这一条建议，则更加的使用，考虑到敏捷开发过程中往往需要不断地检查自己对需求的完善程度，通过不断的Build工程，无疑可以发现很多细节的错误（对需求的误解等等，这是非常有意义的）

《Evolutionary Database Design》

这篇文章作者主要是谈到了敏捷开发（特别是极限编程）下的数据库设计，因为在很多人的观点中，数据库是难以敏捷的，必须在前期完成设计计划，而不是在后期根据需求和实际情况的变化来变化。其实有很多的解决方法，比如数据库管理员和开发者更加紧密地合作，每个人拥有一个数据库实例（作为沙箱），拥有一些测试数据（在移植或者改变数据库的时候用来测试）等等，但是作者并没有谈到一种真正行之有效的方法。也就是说，database evolution problem依旧是没有被完全解决的问题（其实想想是必然的啊！）

《Continuous Integration》

不断地整合，在我看来实际是基于一种极限编程的思想，也就是每天每个人完成了自己的工作后都尽快完成一次整合，这样整个团队就可以完成很多次整合。通过这样的方法，省去了在后续环节中花大量时间整合浪费时间，同时也有助于马上发现bug。

对我的启示就是，很多时候，我们觉得Integration没有什么必要一直做着，但是一旦这么想，往往导致灾难性后果，比如上次我有幸参加了学长的一个游戏项目《奔跑的萝莉》，我们在最后的整合阶段花了非常多的时间，其实通过Continuous Integration这样一种非常好的习惯，我们完全可以避免这样后果的产生。

最后，贴上敏捷软件开发宣言，可能对于每条我都理解得还不是特别的深，但是我将利用我的余下生涯去学习他，掌握好这一个行之有效的软件工程方法。

“个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划”