关于敏捷开发的若干思考

1、敏捷开发中是否不需要文档？

敏捷开发常常需要快速的迭代，因此对文档的需求不如传统开发中那么严格。传统开发中文档一般是作为开发过程中的沟通媒体，而敏捷开发中由于对开发周期的缩短，没有时间编写详细的文档，沟通通过站立晨会等快速沟通方式。文档一般只是作为存档而用。

 

2、产品经理的定位？

产品经理通过于用户进行沟通，确定产品需求，然后再与开发人员沟通，让开发懂得需求。可以说，产品经理通过产品将用户与开发人员结合在了一起。在敏捷开发中，迭代周期短，但是需求常常又非常多。这样如何确定需求的优先级，就需要产品经理和多方进行沟通，更需要由产品经理进行主导。因为这时候公说公有理，婆说婆有理，PK的事情难免。需要考验产品经理的智慧。在一个迭代周期内，尽量安排合适的需求计划，有个短期的目标，并且使这个短期的需求计划在长期的产品主线范围内。此外，定需求的时候，切忌不要定太高而不切实际的需求。

 

3、开发人员只管闷着头开发吗？

如果开发人员只埋头苦干而不问天下事，造成的结果就有可能是导致开发出的产品没人会用，没人能懂。技术实现也许很牛。但是！！记住用户是不关心你如何去做的，而只关心是否能够完成定的目标。

 

4、测试人员需要掌握的技能？

作为一个系统测试人员，除了需要一些业务逻辑以外。还要掌握一些测试工具的使用。在完成系统测试的同时，最好能够指导开发人员进行单元测试，提高开发人员编写代码的可测试性。除此之外，项目组里如果有自动化测试开发人员开发自动化测试框架，在产品有一定的成熟度之后进行自动化测试干预，在此后的迭代周期中，可以有效地减少测试人员的工作量，使其更能关注新需求的测试，对于能够进行自动化测试的，就采用自动化测试方法。

 

5、敏捷要快但不只是快

 敏捷开发需要快，因为只有快速的开发推出产品才能迅速占领市场。但敏捷又不只是要快，追求快而舍弃软件质量的做法也不符合敏捷开发的精神。小步快跑是敏捷的精神。要快跑，但是迈着小步。通过在开发周期中提前介入测试，使用自动化测试方法，推出测试版让用户参与产品质量的提高等方法。可以说，敏捷测试比传统测试方法更加重视产品的质量。力求测试在产品迭代周期中与开发能够部分时间重叠，提升测试的效率。

 

小结：

  敏捷开发与其说是一种方法倒不如说其更多的是一种思想。站立晨会、迭代开发是手段，追求的是一种快速开发高质量软件产品的目的。在下对敏捷软件理解尚欠，还需今后在实践中继续总结，在战争中学习战争。

三、敏捷开发的缺点

　　1，采用敏捷开发，开发团队的人员素质要求比较高。敏捷开发的首要任务是快速，目前提出的"全栈软件工程师"[3]，它要求软件开发人员在开发的各方面：从需求，设计，编码，测试一直到部署都要求是行家里手，可以减少因彼此沟通带来的时耗，这才能保证他在一个Sprint中能独立完成产品中某个特定的任务。显然这样的软件开发人员的素质一定要求很高的，而在软件开发行业中，人员流动率高，新手多的情况下，要做到这一点是比较困难的。

　　2，采用敏捷开发，开发人员与测试人员混为一体，彼此分工不明晰。敏捷开发要求软件人员会测试，测试人员会开发，这在实施起来是比较困难的。这是因为开发和测试人员关注的重点是不同的：开发关注与技术实现比较多，一般都采用正向思维；而测试关注业务比较多，多采用逆向思维。所以一个产品要保证有高的品质，就必须要有专门的测试人员，应该把测试和开发有比较清晰的分工。正如古话所说："术业有专攻，问道有先后"。

　　3，采用敏捷开发，是"短平快"的开发方式，由于产品发布周期短，所以产品的维护，升级等操作的频率也增加了。这必然增大开发人员，测试人员以及运行维护人员的工作压力，在高压的环境下工作容易出错，影响产品的质量。

　　4，采用敏捷开发，不利于文档的建立和修改。敏捷开发有一句口号："拥抱变化"。然而客户需求的变更是经常变化的，这正如当今社会流行所谓"唯一不变的是变化"。为了缩短版本发布周期，特别是在版本发布的之前，当客户的需求发生了变更时，敏捷开发团队仅是修改代码而没有时间修改所对应的文档，这就造成产品和文档的开发不一致性。给产品后期优化，调整或二次开发带来极大的麻烦，在人员频繁流动中更是灾难性的。

　　 四、总结

　　软件工程无非好坏，先进与落后。敏捷开发是个新方法，存在优点，也存在缺点，我们不要一味赶时髦，凡事都一窝蜂。我们要根据自己的企业现状和产品特性，选择符合自己的软件工程方法论，只要这个方法可以给企业提高质量，带来效益，就是一个好的方法。敏捷的特点是版本发布速度快，然而中国又有一句古话："慢工出细活"。活干得快，往往会影响质量，所以我认为对于一些版本发布频率要求不高，或者涉及到严格质量要求的产品，比如航空，航天，金融等领域的产品，不一定采用敏捷开发的方法，可采用更适合于自身产品特性的软件开发方法。我有一位同行，在美国工作，从事金融软件的开发业务，可以想象，这种产品的质量要求是很高的容不得半点差错，所以他们仍旧采用传统的瀑布模型开发方法，他每天从设计师处拿到设计文档，该文档写得很详细，然后按照设计文档进行编码，可以在家里通过互联网工作（公司省去了为员工租用Office的开销），公司效益很好，已经维持了近二十年。

　　[1] 火车模型：软件发布像火车一样，有固定发车时间，新功能是否可发布取决于它是否可赶上这班火车。

　　[2] 探索式测试（Exploratory Testing）：是一种自由的软件测试风格，强调测试人员展开测试学习、设计测试、测试执行和测试结果评估等活动，以持续优化测试工作。

　　[3］全栈工程师：软件从建模，需求，设计，开发，测试到部署，维护都由一个工程师承担。

[原]敏捷开发思考

2012-8-16阅读297 评论0

敏捷开发确实是一个非常不错的开发模式，但是它有太多难以实现的地方。首先就是对开发人员的要求太高。几乎要求每个项目的开发人员都要了解项目架构，熟知各种设计模式原则，有丰富编码经验。这一点很难做到。

对于我这菜鸟来说，看敏捷开发最大的收获就是知道了软件是怎样腐化的，在这里面我看到了自己前一段时间编程的影子。原来虽然知道自己写的代码质量是不高的，但是并不能从客观上把握到底哪里写的不符合标准，这本书里详细介绍了软件腐化的过程和特点。我们为什么说有部分代码的软件质量是不高的呢？虽然好像看起来实现了现在的功能，但是这不部分代码不能应对迎面而来的需求变更。需求变更是一个项目里永恒不变的，编写的代码要有适应性和便于修改性。这就是高手和新手之间的区别。我们要致力于写出便于理解，便于修改的代码。

软件会腐化的特征主要包括：僵化性：设计难以改变，脆弱性：设计易于遭受破坏，顽固性：设计难以重用，粘滞性：难以做正确的事情，不必要的复杂性：过分设计，不必要的重复：滥用鼠标进行复制、粘贴，晦涩性：混乱的表达。要在写代码的时候时刻关注自己的代码是不是脱离了这些腐化性，时刻保持代码的高质量。

我们采用什么样的办法能够保证代码保持干净整洁的设计，而且是高质量的呢？编写的代码要符合以下这些原则：单一职责原则SRP, 开发封闭原则OCP，里氏替换原则LSP，依赖倒置原则DIP——高层模块不应该依赖于低层模块。二者都应该依赖于抽象，抽象不应该依赖于细节。细节应该依赖于抽象，接口隔离原则ISP——不应该强迫客户程序依赖并未使用的方法。当然编码中还有很多编程细节需要去注意，这些原则是基本必须要遵守的。但是我们使用设计的目的是为了让代码更加易读便于理解，更加便于扩展，切记为了设计而设计。