敏捷开发

开发者博客：www.developsearch.com

 

 

目的：就是加快生产，并且保证质量，完全符合业务的前提下，快速交付给客户。

 

为什么敏捷：

1、用户的需求是一直在变化的，我们应该去认识变化，接受变化，拥抱变化。

我们可以通过沟通、重构代码，来满足用户需求的不断变化。通过沟通，可以把需求变化减少，通过重构代码，构建灵活的程序结构，使得需求变化带来的程序修改减小到最少。当然，这一切的前提是测试，开发未动，测试先行，可以把测试代码的编写理解为最初的设计，那么TDD（测试驱动开发）就很自然了。

2、大多数情况下，用户一开始并不知道他想要什么功能，他只是一个简单的描述，随着项目的进展，他看到你做出来的东西，他 才会对他想要的东西做更清楚的描述。所以，在敏捷软件过程中，它将用户的初期需求整理成user story(XP概念)或者backlog（Scrum概念）,然后通过一次次的迭代，和用户一起来开发出想要的软件。

每个Sprint结束以后，要发布可运行的的版本，演示给用户看，同时和用户进行讨论，做的东西是不是用户想要的，另外还要对该 Sprint进行总结

3、相关统计表明,敏捷开发可以将效率提高3~10倍,软件的质量也有更加可靠的保证; 同时,还给团队内的每个成员提供了良好的发展机会,技术和合作水平都能得到相应提高。当然,敏捷的成功前提是其方法本身的适用性和团队对它的深入理解和合理运用。

4、敏捷开发由几种轻量级的软件开发方法组成,包括极限编程、Scrum、精益开发(Lean Development)、动态系统开发方法、特征驱动开发(Feature Driver Development)、水晶开发(Cristal Clear)等等

 

软件过程流程图：

 

 

 

产品原型 ：
建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。
一个常见的问题是软件新的功能与用户想要的不一致。为了避免这一问题，可以模拟真实操作，改进模拟操作过程中难以理解和不清楚的操作行为。

 

迭代开发：

几个步骤：
     需求制定——》需求分析——》设计编码——》测试、功能验证——》发布版本——》下一个周期

1、需求制定：需求方根据上一个版本，提出的新开发需求或调整等。
2、需求分析：开发及测试人员，与需求方讨论并分析新需求，并验证需求的可行性。
3、涉及编码：根据确认后的需求，设计实现方式并进行编码。
4、测试、功能验证：对软件稳定性进行各种测试，并由配合需求方进行功能验证。
5、发布版本：将这个版本发布给需求方。
6、下一个周期：重复1到5步骤。
7、一系列迭代之后，可以只针对测试活动再补充一个迭代。这个迭代可以将重点放在系统测试、与其他系统的集成度、性能等方面。敏捷开发过程中，可能会导致过少的测试文档。如果迭代周期为1个月左右，可以不必对测试文档过于要求，但要制定好测试策略。

 

遵循的原则：
1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3、经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5、在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

 

会议安排：

1、每日碰头会，15钟左右，总结昨天完成了什么，今天要做什么，存在哪些问题等，可以 用Burndown Chart（燃尽图）来形象展示工作进度。

2、评审会议很重要，传统开发模式往往略过该环节，导致一些错误做法不断重复，好的做法无法推广。

3、每次迭代的时候也都要开一个计划会议和评审会议，一般需要的时间可能会长些，比如半天。这些会议的目的就是对工作查缺补漏。

注：开会时，可以将原先的分组打散，让整个团队都参与到项目的需求讨论和测试中来，这样可以突出成员个人，让大家更乐意参与。

 

代码检查：

1、刺激团队成员进行代码重构，我觉得一个可行的方法就是代码检查，团队中的高级程序员可以担当这一任务（当然最好是小组成员都参与进来），通过代码检查，要求开发人员对代码进行重构。

 

测试：

1、编写可测试的需求文档，及早地考虑测试，当需求完成时，可以接受的测试用例也基本一块完成了。

     开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。 规划业务需求，可以采用“3W模板”，也就是：

谁（Who）	是什么（What）	为什么（Why）
消费者/用户	想将归档过程数字化	为了增强沟通，提高分享效率

2、单元测试，通过一段时间的测试代码的编写，让大家觉得开发程序的同时，写测试代码是常态。通过写测试代码，对软件进行重构，增强其 灵活性和可维护性。当大家接受了这一概念以后，接下来的TDD就水到渠成了。那么，自动化的集成测试，验收测试也就不再遥远了。当然，结队编程也是后续将 要采用的实践之一。

3、验收测试，不能再让用户充当我们的QA。除了程序开发人员进行单元测试以外，安排的每个任务在提交之前必须由团队QA进行测试，测试通过才可提交关闭。

 

奖惩：

QA会对验收测试和回归测试中的bug进行统计，代码检查人员也会对程序中需要重构的地方进行统计，当每个Sprint结束的时候，谁的数据最 难看，嘿嘿，你请大家吃一顿大餐吧。谁的数据最好看，奖励一朵小红花，哈哈。这些数据都会在项目管理工具进行公示。

 

 

 

敏捷开发方式能给企业和用户带来以下好处:

     1. 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

     2. 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

     3. 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

     4. 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

     5. 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。

 

主要的敏捷方法：

敏捷开发方法是一组开发方法的统称,主要包括以下几种:

极限编程其主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法,并将它们发挥到极致,结对编程(pair-programming)就是其中比较知名的方法之一。除此之外, 其核心做法还有小规模、频繁的版本发布、短迭代周期、测试驱动开发、持续集成、每日站立会议、共同拥有代码、系统隐喻等。

Scrum Scrum是一个敏捷开发框架,它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中,产品需求被定义为产品需求积压(product backlogs)。所有的产品需求积压都是从一个简单的想法开始,并逐步被细化,直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期,每个Sprint代表一个2~4周的开发周期,有固定的时间长度。

精益开发精益开发的核心思想是查明和消除浪费。在软件开发过程中bug、没用的功能、等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明,然后设法消除。精益开发的其他原则包括强调学习、在最后时刻做决定、用最快的速度交付用户等。

其他敏捷方法还包括动态系统开发方法(DSDM)、特征驱动开发(FDD)、Crystal Clear等,各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解这些方法可以帮助我们从多个角度理解敏捷开发,并且了解更多的最佳应用。

如何选择一种敏捷方法:

选择一种合适的软件开发方法取决于多种因素。在做出决定之前,我们需要充分考虑以下这些方面:

1. 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

2. 社区和业界支持。有较多的社区及行业支持可以使你受益匪浅。

3. 实用工具。一个良好的软件工具可以帮助团队有效地处理日常工作,促进团队协作,并减少管理成本。

4. 对敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

5. 你的团队规模。较小规模的团队最好从简单的方式入手。

6. 你不需要只遵从一种方法。你可以为团队选择一个主要的方法(如Scrum),然后借鉴其他方法。

 

 开发者博客：www.developsearch.com