敏捷开发实践认知
软件开发流程：需求分析 è 设计 è 子系统 è 模块 è 代码
1. 需求分析，如来佛与孙猴子：
杯具程序员：
为API生，为框架死，为debug奋斗一辈子
吃符号的亏，上大小写的当，最后死在需求上！
一说需求，总会触动所有程序员们脆弱的心。在大多程序员的思维里，需求就是圣旨，似乎提需求者是如来佛，程序员成了孙猴子。孙猴子虽有七十二般变幻，但终究逃不过如来佛的五指山。
项目开发后期，突然要添加新功能有木有？十月怀胎，憋了N久的功能不符合当初的需求有木有？…
程序员们怒了，激进地程序员们选择了辞职，或者是熬通宵赶进度。
万恶的需求者们和他们无尽的需求周而复始的折磨着我们的程序员们，直到有一天，传说中得软件帝出现了…
软件帝问程序员，孙猴子，你害怕如来佛吗？
程序员战战兢兢的回答，怕……
软件帝告诉程序员，其实你也可以做如来佛，让他们当孙猴子。
程序员顿悟，从此以后过着幸福快乐的生活。
需求分析初期，客户其实自己也说不清到底想要什么，于是客户总是提出一些模糊的需求。程序员就得分析需求中，那些是必须的，那些可要可不要的，剔除不合理的，增加必须要的。最重要的是我们要发现客户以后可能需要的。
我们尽可能的罗列出现在出现的和将来可能出现的所有需求，摆在客户面前让其选择。
如果客户都需要，程序员要根据时间果断的拒绝掉做不到的。剩下来的需求就是可控制的。
项目开发中遇到需求修改，总是做先完成目前最重要的的版本，快速进入下一期开发。
始终保持总是可以交付的软件状态。
项目开始时就要设定一个最好交付目标，和最坏交付目标。
最重要的是发现目前不需要的需求，但是将来或许又需要的需求，我们要事先预留接口，让孙猴子逃不出我们的五指山。
敏捷开发
简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷宣言遵循的原则
n 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
n 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
n 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
n 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
n 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
n 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
n 工作的软件是首要的进度度量标准。
n 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
n 不断地关注优秀的技能和好的设计会增强敏捷能力。
n 简单是最根本的。
n 最好的构架、需求和设计出于自组织团队。
n 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。
n 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
n 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
n 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
n 粘滞性： 做正确的事情比做错误的事情要困难。
n 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
n 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
n 晦涩性： 很难阅读、理解。没有很好地表现出意图。
敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。
为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：
n 单一职责原则(SRP)
就一个类而言，应该仅有一个引起它变化的原因。
n 开放-封闭原则(OCP)
软件实体应该是可以扩展的，但是不可修改。
n Liskov替换原则(LSP)
子类型必须能够替换掉它们的基类型。
n 依赖倒置原则(DIP)
抽象不应该依赖于细节。细节应该依赖于抽象。
n 接口隔离原则(ISP)
不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
n 重用发布等价原则(REP)
重用的粒度就是发布的粒度。
n 共同封闭原则(CCP)
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
n 共同重用原则(CRP)
一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
n 无环依赖原则(ADP)
在包的依赖关系图中不允许存在环。
n 稳定依赖原则(SDP)
朝着稳定的方向进行依赖。
n 稳定抽象原则(SAP)
包的抽象程度应该和其稳定程度一致。
上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。
敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。
未完待续…