敏捷开发中的实践流程和开发原则

在某些环境下，敏捷开发可以带来的收益并非被所有人知晓。更多的情况下，敏捷软件开发被当做是一种神圣的或者使用范围局限的活动。然而，在国内大多数软件开发者素质平平的情况下，倘若敏捷教练无法通晓敏捷开发的基础知识，那么敏捷软件开发在团队中的实践很可能变成让人懊恼的制度性约束。那么，以下这些知识可以说是敏捷软件开发的核心。

开发原则

那么，或许在某个场合，你听说过“开闭原则”、或者“过度设计”之类的专业术语么？的确，在某些人的口中，能够说出这些词汇的人并不多（只有一次在创新工厂参加面试的时候，面试的那个大牛问到了）。在我看来，作为一个高级软件开发者，这些技能应该是必须掌握的。

1：简单设计

在当前的需求环境下，这样的设计是最好的。

如果要写一个“hello，world”，你是会分析其业务逻辑，对逻辑进行拆分，然后写成不同的类，最后组装到一起？还是只是最简单的方式，一句“printf”解决问题？当然，你可能会说，如果需求变更怎么办？比如输出环境从原来的标准输出，到现在的输出到某个文件，那么这样的设计是否合理？

那么，请看假设：在当前的需求环境下。

这句话意味着，当前的需求环境是目前所有的需求，敏捷开发不处理过渡软件设计。如果你只要我输出一个“helloworld”，那么我绝对不会考虑未知的需求。

可能有疑惑了，敏捷软件开发不是为解决需求频繁变更的问题么？倘若不过渡设计，那么如何应对？

2：随时重构

倘若需求变更，那么重构就会被启动。其实在实际开发中，只要发现软件中的代码冗余或者设计“臭味”，都需要进行重构。

如上面的例子，当你写了一个最简单的“helloworld”时，客户提出了多种输出方式的需求，那么这个时候，将输出部分进行提取和封装，你可能会做一个输入的判断，如：参数等，也会做对应的输出的判断。更有甚者，将输入输出部分进行提取，然后利用接口和基类的方式，同时定义基本方法和通用属性，来满足这种需求。

这样的改动会造成代码混乱和代码冗余。那么启动重构，根据设计原则（SIP、OCP等，后面会说到）对代码进行重构。

重构是随时随地进行的，时间间隔有时会是几天，有时可能只有一个小时，它的意义在于：它帮助杀死代码冗余。

3：开发原则

什么是OCP（开闭原则）？什么又是SIP（单一职责原则）？这些内容传统的软件工程书籍似乎并未提到。敏捷开发中对软件的扩张也是依赖这些原则进行的，尤其是代码重构过程。

OCP（The open-close principle），开闭原则：软件实体（类、模块、函数等）对扩展开放，对修改关闭。

简单的说，当我们抽象出一个基本类的时候，那么这个抽象体一旦被确定，必须是不可修改的。在它之后的开发中，如果遇到功能的扩展或者变更，那么要求只能对其扩展，如重载、多态等，而不能对其内部实体进行更改。

SIP（Single responsibility principle），单一职责原则：就一个类而言，只有一个引起它变化的原因。当软件需要变更时，涉及到的类是否需要跟着变更？倘若是的，那么它符合SRP原则，类跟着变动；否则需要对类进行拆解。再通俗点，一个类只解决一类问题，一个方法只解决一个问题。

另外，还有LSP（Liskov替换原则）、DIP（依赖倒置原则）、ISP（接口隔离原则）等，依靠这些原则，重构的软件重用性高，软件耦合度低。

计划

迭代（sprint）是SCRUM中使用的术语，它将一组庞大的需求，根据时间限度对其进行任务分解，同时保证在一个迭代内需求不能变更。一次次的迭代产生持续集成，最终完成完整软件。在开发过程中，需求相对与最初的需求可以变更，并且欢迎变更，但是在已经计划好的迭代内需求被禁止变更！

任务（backlog）是开发中的具体事务。根据任务分解颗粒度（如以小时为单位），按照任务的耗时程度，每个任务应该在1~4个小时内完成。

立会（stand-up meeting）每天早上花费15分钟左右进行立会，总结昨天做了什么，今天要做什么，遇到什么困难。立会帮助团队掌握开发进度。

反思会（retrospective）迭代结束后进行，回顾迭代中的内容，提出其中的意见并予以解决