敏捷软件开发理念了解

 

学习思路：是什么？为什么？怎么办？

一、敏捷开发是什么？

1、敏捷宣言

个体和交互       胜过  过程和工具

可以工作的软件   胜过  面面俱到的文档

客户合作  胜过  合同谈判

响应变化  胜过  遵循计划

2、原则：

 

　　1） 尽早的、持续的交付有价值的软件以满足客户，是我们优先要做的首要任务。

 

　　2)拥抱需求变更，甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。

 

　　3)经常交付可以工作的软件，从几周到几个月，交付时间越短越好。

 

　　4)在整个项目开发期间，业务人员和开发人员必须每天在一起工作。

 

　　5)围绕斗志高昂的人来构建项目。为他们提供所需的环境与支持，并且信任他们能够完成工作。

 

　　6)在团队内部最高效的传递信息的方式是面对面的交谈。

 

　　7)可以工作的软件是进度主要的度量标准。

 

　　8)敏捷过程倡导可持续发展。出资人，开发者和用户应该尽可能保持稳定的开发速度。

 

　　9) 保持关注先进的技术与设计有助于提高敏捷性。

 

　　10)简单---尽量减少工作量的艺术是至关重要的。

 

　　11) 最好的架构、需求、设计来源于自我组织的团队。

 

　　12）每隔一段时间，总结反思如何让团队变得更高效，并相应地调整自己的行为。

 

 

3、从市场角度思考：满足变化的市场需求以获利

1）用户价值：

人：当市场发生变化时，根据市场反馈的信息和个人经验快速灵活的调整产品，使产品重新满足市场需求，占领市场先机。

产品：产品在满足当前需求情况下，最小化时间和金钱成本，最大化商业价值；同时当需求变化时，产品能够以较低时间和金钱成本满足新需求以获取商业价值。

2）团队价值

人：为满足变化的需求，需要发挥人的创造力，要创造就要给予人更大的自由度。鼓励团队成员不断的学习和尝试新技术和新思想，不要思维固化。为了避免混乱，敏捷开发前提是 成员自我管理能力较高、团队达成共识、成员专业能力较强。

产品：软件必须能够适应变化的需求，必须在最低时间和金钱成本下，对功能进行增删改查。

3）直接沟通和信息反馈

减少因沟通不畅，导致获取不到必要的信息，导致最终产品与真实需求偏离过大。

问题：开发前期一大堆文档，最终产品无法满足客户重要需要且多出很多几乎不用的功能。解决：通过经常的面对面的直接交谈获取用户真实的需求，弱化中间介质文档。客户也是逐渐认识自身需求的。

问题：开发中后期，市场变化了，用户需要对功能简单进行增删改，找到软件开发公司，却发现修改及其困难！解决：软件开发整个周期，甚至投入使用后，必须考虑可拓展性和灵活性。

 

二、为什么提倡敏捷开发？---开发中遇到问题：

1、僵化性：很难对程序进行改动，因为每个改动都会迫使许多对系统其它部分作出改动；

2、脆弱性：对程序的改动往往会导致一些无关的地方出现问题；

3、顽固性：很难解开程序的纠结，使之一些功能成为其它程序能够公用的组件；

4、粘滞性：即做正确的事情比做错误的事情要困难很多，程序对环境和某些不可预料的事情太过于依赖；

5、不必要的复杂性：设计中包含不具任何直接好处的基础架构，换句话来说就是有设计过度的嫌疑，考虑的变化太多，导致系统过于复杂，影响当前功能的实现；

6、不必要的重复：代码中有重复的结构，而该重复的结构本来可以使用抽象和接口进行统一。

7、晦涩性：代码很难阅读，理解，没有很好的表现出意图；

 

三、敏捷开发具体怎么做？--案例分析

 

1、结合自身情况：结合你公司的现状，如组织结构、管理方式、规模、文化等；

1）团队在透彻理解敏捷理念的基础上，灵活的选择或创造最适合自己的实践，避免教条化！当察觉自己陷入教条化时，要问自己敏捷开发是什么？为什么采用敏捷开发？怎么做？

注释：教条化，也叫教条主义、本本主义，是一种僵化的态度。要么一切从已有理论出发，要么一切以主观出发，而不从实际出发，不客观思考，反对具体情况具体分析，否认实践是检验真理的标准。

 

2、Scrum--侧重于项目管理

（1）三大角色：

产品负责人（Product Owner） 个人感觉就是：产品经理。

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

敏捷教练（Scrum Master） 个人感觉就是：项目经理。

主要负责整个项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

敏捷团队（Scrum Team）  个人感觉就是：开发团队。

主要负责软件产品在Scrum流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达待办事项或迭代清单（Sprint Backlog）的目标。

（2）Scrum--迭代开发流程：

1）产品负责人确定产品列表（Product Backlog），按优先顺序排列；

2）敏捷团队根据产品列表，做工作量的预估和安排；

3）团队召开迭代计划会议（Sprint Planning Meeting） 从产品清单中挑选一个用户故事（Story）作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个用户故事进行细化，形成一个待办事项列表；

4）每个成员根据待办事项清单再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5）每日站立会议，控制在15分钟左右，每个人都发言，内容：昨天做了什么，今天要做什么，是否需要帮助？会后大家在任务看板上更新自己的任务纸条。

6）每日集成，每天下班前单元测试代码通过，签入代码并且编译通过；工具：TFS或SVN。

7）当一个用户故事完成，也就是待办事项列表被完成，也就表示一次迭代完成，这时进行演示会议（Srpint Review Meeting），也称为评审会议，产品负责人和客户都参加，团队成员向他们演示自己完成的软件产品；

8）最后就是 总结会议（Sprint Retrospective Meeting），以轮流发言，交流自己的收获和不足，放入下一轮迭代的产品需求中。

 

注释：

任务看板（白板、黑板）包含：未完成、正在做、已完成的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。

 

2、极限编程（XP-）-侧重编程实践：

1）价值观

沟通：修改他人代码是要及时口头沟通，避免混乱和返工，文档、报表、计划来不及；

简单：够用就好，不要冗余设计；

反馈：经常与客户互动、单元测试、持续集成（签入编译成功）、

勇气：重构、

谦逊：互相尊重、编码规范

 

1）实际操作

（1）完整团队：业务人员或领域专家和开发人员尽可能在一个房间；

（2）用户故事：从产品列表中提取来的一组重要需求，细化为可自行的待办事项列表；

（3）短交付周期：前提条件是新版本有足够商业价值。

（4）结对编程：一个编码一个检查，然后轮换；

（5）测试驱动开发：先单元测试在编码；

（6）重构：先编写代码在进行重构。

（7）代码集体所有：共同所有共同负责。

（8）持续集成：提前暴露集成问题。

（9）隐喻：打比方，用客户听的懂的语言和客户交流。

（10）计划游戏：软件的范围、下一次迭代的发布时间、用户故事的优先级应该由业务人员决定；而每个用户故事所需的开发时间、不同技术的成本、如何组建团队、每个用户故事的风险，以及具体的开发顺序应该有开发团队决定。

（11）简单设计：反思“我们可以预测变化”和“需求不会发生改变”的错误，然后做出合适的设计。

（12）编码规范：在编码中逐渐形成统一规范。

（13）拒绝加班，丰富业余生活。

 

五、对敏捷的常见误解：

1、敏捷开发意味着不需要文档、设计和计划；

2、敏捷只适用于小项目开发；

3、敏捷只会对研发产生改变；

4、管理者不需要亲自了解敏捷，只需要管理上支持就可以了；

5、引入敏捷只需要按照既定的步骤去做就可以了；

6、敏捷只是管理者的噱头，跟编码人员无关；

7、敏捷只注重特性的快速交付，在敏捷下架构不重要了。

极端错误：敏捷开发能解决一切实际问题，好像它是完美无缺的；反之，发现敏捷开发也有解决不了的问题时就全盘否定它的优点。

 

六、设计原则

1、SRP：单一职责原则

思想：高内聚，低耦合；

应用：一个类应该仅有一个引起它变化的因素。

 

2、OCP：开发封闭原则

对扩展是开发的：出现新需求，模块能够进行功能扩展。

对于更改是封闭的：对模块扩展时，无需对原有程序代码或dal文件重新编译。

方法：接口封装、抽象机制、多态思想。

 

3、LSP：里氏替换原则

子类可以替换父类并出现在父类能够出现的任何地方。

 

4、DIP：依赖倒置原则

高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。

 

5、ISP：接口隔离原则

模块间要通过抽象接口隔离开，而不是通过具体的类强耦合起来。

 

思考：

1遵循敏捷设计去发现问题；

2应用设计原则去诊断问题；

3应用设计模式去解决问题；

注意：应用敏捷设计、设计原则、设计模式都是为了解决实际问题，切勿盲目套用，否则会导致设计难以理解的复杂性和代码的冗余。

 

参考资料 1敏捷软件开发解读--华为2009年

http://wenku.baidu.com/link?url=Chsf6BgfKY0BCmOLUAq5qn6znhHe4-3HCNAEw4UYua3O_B6x817wqb3hBu3erBMopdGOqb6lyWnxDMgCmAPhEZlv2LTwnDr7DcHQ4glyWEa

2敏捷开发之XP --博客园博客

http://blog.csdn.net/fw0124/article/details/48713959

3、敏捷开发之Scrum扫盲篇 ---CSDN博客

http://www.cnblogs.com/taven/archive/2010/10/17/1853386.html

4、敏捷软件开发：原则、模式与实践（C#版）/Martin.R.C著 ，邓辉、孙鸣译