敏捷开发中story定制_敏捷开发中story - CSDN
  • ■User Story 是什么? User story是对软件的用户或买主有价值的功能点的描述。 1.他是用来制定计划和作为提醒的一段书面描述 2.用来充实story的细节的谈话 3.测试用例,用来表达和记录细节并且能够在story实现...

    ■User Story 是什么?
    User story是对软件的用户或买主有价值的功能点的描述。
    1.他是用来制定计划和作为提醒的一段书面描述
    2.用来充实story的细节的谈话
    3.测试用例,用来表达和记录细节并且能够在story实现的时候对进行验证
    每个Story都有每个Story存在的价值,编写stories的关键点在于让客户让你们的主管和经理们认可Story的价值。

    ■如何去编写Story
    1.使用5W1H的方式去编写Story
    5W1H:what, when, where, why, who, How
    在编写Story的时候,用尽可能短的语言去表述清楚what,where,why就可以了
    至于How,when, who则可以在planningMTG中通过和客户,领导等沟通去决定。

    Story例:某某功能的内部処理を設計、実装和测试
    问题点:某某功能是what?这个Story的完成基准又是什么?在这个例子中,都没有明确的说明。那么该如何去判断做什么,又如何去判断完了呢。
    在优秀的软件中,每一行代码都为了完成一个或者多个功能而存在的。在Story中把真正what, where, why用最简单的方式去说明清楚吧。
    設計、実装、测试、DR等等是How,是为了完成这个Story的手段。
    因为Story做成提倡尽可能短,所以不要将How放入Story中。将How作为Story的一个补充说明才是上上之策。

    2.一个Story必须要有一个明确的Goal
    简单来说一个Story在作成完了后,必须能够判断他的Goal条件。如果Story中无法明确传达Goal条件的话,也就失去了用Story来管理进度的意义了。
    至于你使用机能点还是测试点或者是成果物单位来对Story进行分解,这个是次要的,关键是每个Story要有一个明确的完成基准。

    3.根据是否有明确的最终Goal分开考虑作成Story
    明确最终Goal的项目中,用TopDown的方式,分解Story,每一个Story就是一个Goal,所有的小Story达成后,最终Goal也就达成,如果你的Story中有和最终Goal没有关系的小Goal,那么就把这个Story果断的去掉吧。
    当没有明确最终Goal的项目中,用BottomUp的方式,把眼前能够要做的该做的先做好后,再去和客户检讨式样把。检讨以后再作成Story。如果能做到的话,就可以"拥抱变化"了。

    4.不明确事项,检讨项目也需要管理
    项目开发过程中,有太多的TBD项目,有太多的暧昧的地方,这就是软件开发。
    这些地方也请你用Story或者其他方式将他管理起来,在早会时定期联络。不要在你的Story中出现这些不确定的内容。
    如果你的Story因为某些不确定原因而无法着手的话,请果断将这个Story挂起,并及时通知ScrumMaster吧。

    ■如何去使用Story
    1.Story需要定期维护吗
    在刚开始软件开发的阶段,并不需要也没有必要把所有的Story都分好详细列出,因为软件开发中存在太多的不确定的因素。客户的需求也不是一成不变的。
    刚开始只要列出一个完成开发的大致的脚本就可以了,当真正开始做之前,再把故事脚本细化为可以量化的Story。什么时候明确了需求,再去考虑为了完成需求的具体的Story。理论上在PlanningMTG的时候把近1~2周的计划列出来,进行相对的工作量估算后,就开始冲刺。如果能够这样的话,团队的效率是最高的。
    所以敏捷开发中提倡的就是一边开发一边去作Story。

    2.StoryPoint如何确定
    根据书上所说,先选出一个大小适中的Story作为模板,将Point分为1,3,5,8,13等相对数值来标示一个作业的工作量。每个Story最好能够在3天之内完成。
    我觉得相对于花时间去想去决定Point,还不如把时间花在项目本身上,Point只是一个工作量的标示罢了。每个项目都有每个项目的特殊性,Point也好,对一个Story使用百分比也好,只要能够将进度实现可视化就可以了。

    3.进度的自我管理
    用Story管理也好,用白板管理进度也好,用其他的进度管理方式也好。都只是进度管理的方法而已。真正清楚进度的人并不是项目主管,项目经理,也不是客户,应该是担当该要件的人。当你发现进度提前或者落后的时候,就主动想好原因对策以后,找ScrumMaster沟通吧。世界上没有完美的项目进度计划,项目中每个人的进度情况构成了一个项目的进度情况。使用好Story去管理进度,而不要依赖于Story去管理进度。

    4.Story仅仅只是为了进度管理吗?不是。
    进度管理只是他一部分的作用,利用Story不仅仅是进度管理,Story也是要件担当者和项目关系者(主管,项目经理,测试员,客户)之间的一个沟通模板。
    利用好这个沟通模板,才能更好的挖掘出客户的潜在需求,才能更好的将自己的成果频繁主动的展示给你的项目经理。拿着你做好的Story主动和他们去沟通吧。
    敏捷开发提倡频繁的沟通,如果没有良好而频繁的沟通,Story的作用效果也就大打折扣了。

    结束语:如果一个要件是一部电影的话,担当要件的人就是总导演,Story就是为了完成电影的一个个镜头。在设计软件之前,请先设计好你的Story把。一个个短短的镜头就构成了一部电影。做一个优秀的导演,从先设计好一个个短短的镜头(Story)开始。

    展开全文
  • 因为我们的工作有各种事物要处理,我们需要这样的敏捷开发工具来帮助我们解决问题并清晰的展开工作。Leangoo可以帮助我们管理事务,需求管理,迭代管理,缺陷管理,测试管理,排列优先级等,随时随地可以了解到...

    为什么选择 Leangoo

    很简单,因为它够简洁,够轻量,上手够快!

    因为我们的工作中有各种事物要处理,我们需要这样的敏捷开发工具来帮助我们解决问题并清晰的展开工作。Leangoo可以帮助我们管理事务,需求管理,迭代管理,缺陷管理,测试管理,排列优先级等,随时随地可以了解到团队以及项目的进展情况。

    可以在Leangoo中,定制你和团队的工作流,任务分配,实时同步,每个成员都可以最快速度了解到被分配的任务,与团队更好的协作。

    所有的项目进度,需求趋势,缺陷趋势都可以一目了然。

    也可以利用Leangoo的思维导图,可以把卡片通过树形结构组织起来,用来管理创意,知识,需求,测试案例等等。

     

    亮点:

    1. 轻量,操作简单,上手超级快。

    简单不意味着要以牺牲功能作为代价。Leangoo的核心是看板,整个页面设计很友好,可以直观的对任务一目了然。它配置性强,可灵活自定义,大量的操作都以拖拽的形式进行,并支持大量的快捷键!

       2.完美支持Scrum敏捷开发和看板方法

    Leangoo的设计融入了先进的敏捷管理思想,由多位业界知名敏捷管理顾问提供支持,并由专业的敏捷开发团队精心研发,完美支持Scrum敏捷开发和看板方法(如:燃尽图,工作量估算,看板周期等),并且可以轻松对接主流Devops平台,是敏捷研发团队首选的项目管理和协作工具。

       3.管理任何事务

    Leangoo可以管理任务事务,比如:

                 1).管理产品/项目规划和敏捷需求,协作进行需求。

                 2).管理敏捷迭代任务,进行任务协作

                 3).管理缺陷,进行缺陷处理的协作

                 4).管理测试场景和测试案例,进行测试协作

                 5).可视化跟踪项目和迭代的进展

     

       4.思维导图

    一个共享的思维导图,可以把卡片通过树形结构组织起来,用来管理创意,知识,需求,测试案例等等。

    可以多人协作,多人在线编辑,实时同步!

    看板统计:

    Leangoo的每一个看板都设计了看板统计功能,比如:

    1. 燃尽图——项目完成之前,对需要完成的工作的一种可视化表示。
    2. 任务周期——可查看每个任务所花费的时间
    3. 任务分布——可查看每个成员的任务分布情况

    项目跟踪:

    在项目管理的角度,Leangoo也提供了一些统计,比如:

    1. 项目进度 —— 项目进度是根据项目里面所有的需求看板进行统计的,进度值 = 已完成的工作量 / 总的工作量
    2. 团队速度——一个迭代中实际完成的工作量(单位通常是故事点数)
    3. 缺陷分布——展示项目中缺陷的分布情况,(下图所示)

    项目占比的设定以及每个成员参与的项目数量等

     

     

    企业管理:

    在企业管理的角度,Leangoo也提供了一些统计:

           企业仪表盘——整个企业仪表盘上展示了项目状态,需求趋势,缺陷趋势,吞吐量。

    • 项目状态

    项目状态饼图使用了红黄绿三种颜色来代表项目的健康状态。
    绿色表示项目的进度正常,红色表示项目进度有延迟,黄色则是指项目在红绿之间的临界状态。
    通过该饼图能对企业中所有项目的健康状态有大致的了解。
    其中:项目的健康状态是根据项目的需求看板的实际剩余量与燃尽图参考线的偏差进行判定的

    • 需求趋势——需求趋势统计的是每个月需求的变化趋势。
    • 缺陷趋势——缺陷趋势统计的是每个月缺陷的变化趋势。
    • 吞吐量——吞吐量统计的是每个月所有项目完成的需求总和、缺陷总和。

    项目列表:

    项目列表统计的是企业内所有的项目,统计项目进度、需求数量和缺陷数量,资源总数等

    集成

    Jenkins

    API接口

     


     

     

    展开全文
  • 很多人认为软件质量是软件是否存在 Bug,是否性能高,安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于某个(或某些)人的...本文将和大家一起探讨软件质量的含义,以及敏捷开发中如何进行高质量软件的

    很多人认为软件质量是软件是否存在 Bug,是否性能高,安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于某个(或某些)人的价值;价值是指创造利润,又或是降低成本。总的来说,软件质量是软件的灵魂和存在意义。敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论,敏捷开发是追求高质量软件的方法论和过程。

    本文将和大家一起探讨软件质量的含义,以及敏捷开发中如何进行高质量软件的开发。

    陈 序明, 架构师, EMC

    孙 沛, 产品开发经理, EMC

    单 建洪, 首席架构师, IBM

    2009 年 10 月 28 日

    • +内容

    前言

    什么是软件质量?很多技术同仁都认为软件质量是软件是否存在 Bug,是否性能高,安全性好等等。其实软件质量的含义远多与此。质量就是软件产品对于某个(或某些)人的价值;价值是指创造利润,又或是降低成本。总的来说,软件质量是软件的灵魂和存在意义。另外,我们知道现在敏捷开发日趋流行,其实敏捷开发也是顺应市场的对价值的诉求和日益复杂的业务而产生的方法论,敏捷开发是追求高质量软件的方法论和过程。

    本文将和大家一起探讨软件质量的含义,以及敏捷开发中如何进行高质量软件的开发。

    软件质量的理解

    首先,我们先来看看什么是软件产品质量?先有了软件质量定性的了解,才能介绍如何影响、控制和改进质量。

    大师温伯格在《质量·软件·管理系统思维》说到:“质量就是软件产品对于某个(或某些)人的价值”(某个或某些人文章中统称之为用户),这里面包含两个层次的质量含义,即“正确的软件”“软件运行正确”

    1. “正确的软件”是说,一个软件要能够满足用户的需求,为用户创造价值。此处的价值可以体现在两个方面,即为用户创造利润或者减少成本。如果一个软件能够满足需求的用户群体越大、创造的利润越大或减少的成本越大,则该软件产品的质量越高。反之,一个产品尽管运行良好,没有 Bug,扩展性很强,性能很好,但如果没有服务的用户人群,没有为用户创造价值,则这样的软件尽管运行良好,也无任何质量可言。
    2. “软件运行正确”是说软件没有或很少 Bug,扩展性很强,性能良好,易用性高等。这样的软件是一个运行良好的软件,但还不能称之为高质量的软件。只有在软件符合用户的需求的基础上,运行良好的软件,才是一个高质量的软件。当然,如果软件完全符合用户需求,但不易使用,经常出错,性能很差,这样的软件也不是一个高质量的软件。

    “正确的软件”及“软件运行正确”二者相辅相成,前者关系到软件的成败,后者关系到软件的好坏。在现实的很多开发团队中,特别是偏技术的开发团队中,往往过分注重后者(软件的 Bug 率,性能,可扩展性,架构等),经常陷入在软件开发过程的细节之中,而忽略了前者(软件需要符合用户的需求),开发出的软件经常能用但无用,不是最终用户期望的软件,这样的软件是能用但无用零质量软件

    在产品开发中,能用但无用的现象尤为明显。产品和项目不一样,项目往往是为某个客户而开展,有特定的需求来源,而产品往往是一个更广泛的概念,是市场上某一类客户群体的价值代表,没有固定的需求来源,而且良好的产品往往要起到引导客户需求的作用,超越现有客户能提出的需求,所以对产品来说,“正确的软件”更加困难,但也更加重要。

    当然,“软件运行正确”同样非常重要,关系到软件的好坏。Bug,扩展性,性能,易用性等问题会造成客户想用但用不了,同样造成软件质量问题。

    敏捷开发对软件质量的影响

    敏捷开发对软件过程和质量控制产生了一系列的影响,主要来自两个方面的影响,用下图表示如下:

    图 1. 敏捷过程带来的影响
    敏捷过程带来的影响

    图中的具体含义如下:

    1. 敏捷开发对“正确的软件”的影响

    敏捷开发拥抱市场变化,拥抱客户需求变化,采用迭代反馈的方式管理项目。其背后的一个核心理念是:一个高质量的软件,首先应该是一个“正确的软件”,能够满足客户的需求。

    我们知道当今的世界产品极大丰富,不管任何产品都会有的竞争对手和替代产品,大家熟知的有浏览器大战,输入法血拼,视频网站、博客满天飞,国内外 ERP 系统竞争激烈等。所以,软件的质量是要在市场化的竞争激烈的环境中去进行验证,进行优胜劣汰,最终高质量的软件产品被客户接受。所以,一个高质量的软件首先应该是一个“正确的软件”,能在激烈的市场和竞争对手中找到市场定位,有客户需求和市场销量,能提高产品的使用者客户体验的软件。否则,软件做的再好、性能再快、界面再优美好用也不是一个高质量的产品。

    敏捷开发正是符合这样市场环境而诞生并流行,其迭代反馈、拥抱变化的理念和方法,能够使得团队更能开发出符合市场和客户的高质量软件。如上图 1 中所示,左图中的大半圆表示传统的开发模式中,产品不能满足客户需求的风险。因为传统的开发模式基于中央控制的计划,没有足够的迭代和反馈理念和方法,犹如一次性的把所有的资金购买了一只股票,导致质量风险大。上图 1 中右边的敏捷开发中,采取迭代反馈的原理,通过一系列的方法(下面会介绍)把市场和客户的需求和期望分散到个整个软件的生命周期中,犹如把所有资金进行资产组合,最后的软件产品质量风险小,能够较大概率的符合市场和客户的需求,并带来价值。

    敏捷开发响应市场和客户价值取向,但如果没有完善的方法去收集和分析市场和客户的反馈,也会导致严重的质量问题,如软件随波逐流,随客户朝夕更改;市场定位模糊,没有核心竞争力;和竞争对手没有任何区别,陷入艰难的红海战争中等。所以,敏捷开发方法对高质量软件也提出了挑战,需要相应的方法和流程去执行和控制。

    1. 敏捷开发对“软件运行正确”的影响

    “软件运行正确”是说软件运行良好,没有或很少 Bug,扩展性很强,性能良好,易用性高等。

    软件工程中有个经典的统计,即软件生命周期的前期造成的 Bug 的影响比后期大的多,所以需求的变动影响是最大的。而敏捷开发拥抱市场变化的理念,会积极响应市场需求,这会对整个软件,如软件架构、编码、测试、文档都会造成很大影响。犹如长鞭效应,长鞭前端的抖动会逐渐放大到整条长鞭,而且波动会越来越大。这会影响“软件运行正确”的高质量要求。

    所以,我们不仅要看到敏捷开发带来的高质量客户价值的好处,如上图 1 右边敏捷开发的上部分波动所示,还要看到这些小波动导致的长鞭效应。如上图 1 右边下半部分所示。敏捷开发拥抱市场变化和客户反馈会对整个软件的架构、开发、测试造成很大的波动。如果控制不好,会使得项目失控,造成严重的质量问题,如错误 Bug 多,架构不合理,易用性不好,性能不好等等。

    总的来说,敏捷开发的理念和方法,响应市场和客户的价值,有利于发布符合客户价值的软件。下面介绍敏捷开发过程及质量控制最佳实践,能很好的解决敏捷开发中的软件质量问题,辅助团队发布高质量的软件。

    敏捷开发过程及质量控制最佳实践

    敏捷开发的需要敏捷过程的支持才能快速响应市场需求,发布高质量的软件产品。下图是作者用过的敏捷过程(可以定制适合自己项目的敏捷过程),文章不详细介绍下面敏捷开发过程,主要介绍其中的质量控制流程及最佳实践,也是围绕质量的两个方面介绍质量控制实践:“正确的软件”及“软件运行正确”两方面。

    下图 2 中是一个软件敏捷开发的迭代过程,每个迭代有需求,有变化,有架构,有设计,有开发,文档等。其中深蓝色背景,白色字体的是敏捷过程中质量控制流程。主要包括两个方面的质量控制:“正确的软件”及“软件运行正确”两方面。下面依次介绍:

    图 2. 敏捷开发过程及质量控制
    敏捷开发过程及质量控制

    查看大图

    “正确的软件”的质量控制流程和最佳实践

    这个作者认为是敏捷开发中质量控制中最重要的一点,因为这是后面所有其他软件质量的前提。如果软件刚开始就是错误的,不能给客户带来价值的,就犹如路和方向就是错误的,那尽管在这条路上走的多好,多稳,也不会通向理想的目的地– 高质量的软件。做正确的事情,说起来简单,但做起来是最为困难和艰险的一件事情。犹如上文说到的长鞭效应,在这里一步走错,就会导致整个软件的极大波动,导致项目失败。因为产品定位和价值都错了,那再如何努力开发和测试也是不可能交付高质量的软件。敏捷开发强调拥抱变化,迭代开发,客户反馈原则等也无非是使得软件在正确的方向上前进。

    下面作者敏捷开发过程中经常使用的几种最佳实践,能够辅助团队正确捕获市场需求和客户反馈,并进行需求分析及过滤,设计出能给客户带来价值的高质量软件。包括上图中的“需求”、“SWOT 分析和需求审核”和“CDD & User Story 审核”。

    1. 需求

    需求又包括需求获取和反馈,需求分析和需求创造三个方面

    演示和原型

    在软件敏捷开发过程中,如何获取市场的需求和客户的反馈是高质量软件的前提。敏捷开发中,除了正式的软件开发及发布,我们还有专门的团队开发演示和原型。演示是为了向客户和业务人员展示产品功能,并获取客户反馈;原型是为了展示对产品未来的雏形和概念,便于与客户讨论和展示,并获取市场需求。产品、原型和演示三者的关系如图所示:

    图 3. 敏捷开发过程中的软件、原型和演示
    敏捷开发过程中的软件、原型和演示

    Persona 的方法论

    Persona 指的是角色,也就是基于角色的方法论,强调一切从角色出发思考问题。我们知道,每个人的思考的角度都不一样,客户的思考问题的角度和开发团队的思考角度不一样,甚至不同客户之间思考问题的角度也不一样。团队在设计和开发软件的时候,容易陷入自己的思维角度,开发不符合客户思维角度的软件,而不符合客户的需求。更严重的是很多团队陷入这样的惯性,而根本不知道错误在哪里。

    Persona 的方法论中强调,不论软件的哪些需求,哪个功能模块,甚至会议中的讨论,请首先确认出 Persona。Persona 可能不止一个,所以需要分析并确认出不同的 Persona,并设定所有 Persona 的背景,需求,期望等。然后把讨论的需求、功能模块、会议的议题,对应到定义的 Persona 中。然后根据 Persona 的重要与否,Persona 的背景等,就可以进一步分析、确认需求。下面是一个 Persona 的简单模板

    Persona 的简单模板:

    • Name
    • Photo
    • Brief Biography
    • Goals
    • Context scenario

    确认出 Person,尤其是关键客户的 Persona,然后尽量使软件符合该 Persona 的价值需求。作者的经验中,Persona 的方法论,非常有益于理清思路,特别是在需求分析和讨论阶段尤为重要。需求收集和讨论时,不同的同事代表不同的 Persona(有的是客户业务人员,有的是客户架构师,有的是客户技术人员)他们提出各种不同的假设、需求、改进、功能模块。这时如果不从 Persona 的角度去思考和理清问题,就经常陷入混乱和口水大战。而最终却没有满足项目或产品的最重要 Persona 的需求,不能创造价值。可想而之,以此为基准的软件将是能用但无用的零质量产品

    最高境界“跟随需求,不如创造需求”

    这点对软件产品来说尤为重要,前面说过产品和项目不一样,产品的需求更加模糊,而且一些新产品往往需要带有一定的新特性。产品需求的最高境界是创造概念、规则,并由此创造需求。不管是软件行业,还是其它商业界都是如此,如:

    1. 从 BP 机到手机,再到 iPhone;
    2. 从胶片相机到数码相机;
    3. 从门户广告到搜索广告;
    4. 从 Blog 到 Twitter 等

    商业界创造概念、规则、模式,并由此创造需求,才能创造出蓝海,并成为领头羊。而其他跟随着只能符合创造者的提出来需求。

    在这个境界上,创新是最至关重要的因素,唯有创新才能打破规则,打破需求跟随者的状态,创造出符合未来用户需求的规则和产品。

    而这样的软件,也是最有价值的高质量软件。

    1. SWOT 分析和需求审核

    敏捷开发中通过需求收集及客户反馈得到了大量的客户需求,如何进行有效的过滤并选出最有价值的需求呢?这是敏捷开发中高质量软件的关键之一,因为没有一个很好的以客户和市场为中心分析方法,产品会随客户朝夕更改,市场定位模糊,散失稳定的核心竞争力。

    开发团队常见的误差是从技术的角度来考虑哪一些需求价值大,哪一些需求紧急度高,造成的结果是有一些功能模块投入了很多资源,但却并不一定是客户最想要的。

    在作者的敏捷开发中,对产品的需求和模块进行 SWOT 分析,分析的输入是所有的 Persona 客户需求、市场现状、产业现状、竞争对手现状等,输出是需求的重要度和紧急度,以及投入的成本。然后按照性价比可以进行排序,选出最能符合市场的模块。SWOT 分析有益于以最少的投入研发出符合客户和市场价值高质量的软件。

    下面是一个 SWOT 分析的事例:

    图 4. SWOT 分析事例
    SWOT 分析事例
    1. CDD 以及 User Story Review

    CDD(Concept Design Document)指的是软件的概念设计文档,User Story 指的是用例细化的用例故事。

    这二者发生在进一步细化需求并要转换成软件架构时,对这二者进行进一步的分析和审核,有益于保证从需求分析到架构设计的过度阶段的软件质量,降低客户需求理解偏差的概率。

    “软件运行正确”的质量控制流程和最佳实践

    敏捷开发的拥抱变化,如上面的图 1 中所示,会对软件架构、编码、测试、文档都会造成很大影响,犹如长鞭效应,长鞭前端的抖动会逐渐放大到整条长鞭,而且波动越来越大。在敏捷开发中,为了快速响应变化,敏捷开发中的如下特性:

    1. 需求变化更频繁
    2. 轻详细设计,没有那么多的架构和设计的时间
    3. 反对冗余繁重的文档
    4. 反对冗长会议和电话会议
    5. 赞同代码就是最好设计和文档(Code is design and document),并通过重构自然呈现架构和设计

    这些特性和传统的进行大量的架构设计,然后通过文档记录并沟通的方式有很大差别。敏捷开发中这样灵活的方式就更要求有严格的质量控制流程。否则,最终的产品的质量很大概率出现问题。如可扩展性、架构、可用性、测试稳定性 Bug 等。

    下面是敏捷开发流程中控制架构、开发、测试等质量的流程:

    1. 架构和概要设计 Review

    敏捷中轻详细设计,但并非不注重设计,只是敏捷中架构的形式和内容发生了变化。敏捷中进行的架构设计是高层次的架构设计,如:组件的结构,软件的层次,技术选型等。敏捷中没有进一步的详细设计。架构设计就显得尤为重要,架构层次的错误,在后期需要大量的人力物力来弥补。架构和概要设计审核主要围绕下面几点:

    1. 组件结构是否清晰。围绕组件的特性:“高内聚”、“松耦合”、“隔离性”、“颗粒度”、“分层”等特点,设计良好的组件结构。组件的抽取过程,可以在公司组织结构部门设立中找到似曾相似的影子。在公司组织结构中,任何事情重复或重要到了一定程度,就会产生一个新的部门,如做销售的人多了,就产生了销售部门,不同省的销售多了,就产生了省分部门。在架构设计中也是一样,任何功能重复的到了一定程度,就应该抽象出新的组件,甚至一个产品。在设计好组件结构后,就可以分工进行开发。
    2. 层次结构是否清晰。关系是否混乱?是否需要抽取单独的层次?
    3. 是否符合 Do not repeat yourself 的规则。好的架构设计应该是“不重复自己”,并且“不重复已有的成熟组件”。尤其是当架构中有些功能有免费成熟开源框架或者标准可以依据,但架构设计时没有采用考虑,而重新发明轮子,导致不能重用已有的标准或开源框架的优势,这些都是不可取的。
    4. 技术选型是否合理。包括数据,模型,展现,逻辑等技术选型,以及使用框架,依赖产品等。
    1. 代码审核,以及重构出设计

    传统的架构设计,包括架构和设计两个方面、其中设计可以包含详细设计,如详细的 UML 图(详细的类图,顺序图等),详细的 API 设计以及接口描述,存储层数据库表字段设计等等。敏捷开发中不进行详细设计然后再开发,它推崇 Code is design,设计是通过对代码进行重构自然产生。所以,敏捷开发中,代码质量和可读性很重要。是否能通过高质量的编码,以及重构,自然呈现出软件设计,关系软件可维护性,Bug 出错率和修改、可扩展性、稳定性、甚至性能等质量问题。所以,在敏捷开发中并非没有详细设计,而是详细设计的方式和时机发生了变化:敏捷开发详细设计转移到了开发阶段,也即是:Code is design。这样既能拥抱变化,又规避风险,又 Don’t Repeat Yourself。

    敏捷中代码审核的质量规格应该类似与详细设计的规格,要求开发人员能够发布高质量的代码及代码结构。团队可以设立统一的编码规范,命名规范,代码结构规范。确保代码和代码结构的质量。团队也可以选用一些自动化的代码扫描工具来分析代码结构及存在的不合规范的地方。

    开发规范是能提高代码质量,好的代码,结构清晰,读起来毫不费力,是一种享受。好的代码包括如下特性:

    1. 高质量代码结构在于开发人员不断重构,把代码按照逻辑结构分成不同的包。
    2. 高质量的代码格式一般可以通过工具中的编辑器的代码模板和格式器来控制。
    3. 高质量注释即是代码的注释,又是软件的设计文档。
    4. 这里强调一点是高质量的命名,不管是包命名,类命名还是变量命名,命名时应该采用能够让人看懂的名字,名字长一些往往更好,尽量少用不清晰的缩写。如:People 对象,应该用 people 等能够一目了然的命名,而不是 p, pe 等简短不清晰的命名。
    1. 测试流程

    在讲测试之前,我们重新回顾一下:什么是“高质量”的软件产品?只有统一了“高质量”的概念,测试人员才有测试的标准和最后交付软件的标准。

    “高质量”的软件,可以认为是:能为客户在最少时间内,带来最大价值的软件。测试人员在测试软件的时候,应该在思想层次和终端用户统一“高质量”软件的认识,并且所有的测试标准也将围绕这个“高质量”的衡量标准进行,否则测试结果为高质量的产品,对客户来说可能就未必是这样。

    所以测试团队在软件测试的过程中,要时刻站在客户的角度思考问题,设计测试用例,以及测试产品。敏捷开发中的测试包括功能测试、集成测试、性能测试、安全测试、可消费性测试和无障碍测试等,这些确保能够按照设计发布高质量的软件。这里不细讲每一个测试的环节。需要强调的是可消费性测试。

    一个高质量的软件,不仅要能够按照既定的设计良好运行,还应该是一个很好用的软件。只有客户能够方便的使用软件,软件才能为客户创造价值,也才能称该软件为一个高质量的软件。大家都很熟悉的 Windows 和 Linux 操作系统,从普通终端用户的角度上考虑,无疑 Windows 是更高质量的产品,因为它能为客户在投入最少时间的情况下,创造最大化的价值。而 Linux 我称之为技术层面的高质量产品,对普通终端用户来说,其综合价值不如 Windows。

    可消费性测试涵盖了整个软件生命周期,将在另外的文章中详细介绍。下面的可消费性测试中易用性测试几个常用的原则,它能够帮助测试人员测试软件的容易使用程度。

    1. 效率– 用户要花多少时间,多少个步骤才能完成一个任务。比如注册用户,查找一篇文档。
    2. 准确– 在操作的执行过程中,用户犯了多少错?测试人员要时刻记住,用户在使用产品中犯错,是设计人员的错,而不是用户的错。
    3. 无需记忆性– 用户第一次使用是否能容易的使用产品?或者用户多长时间不用后,还能记得如何操作产品?好的产品设计是无需用户记忆,一切使用规则是隐含在设计中。
    4. 情感反映– 用户完成任务后的感觉是什么?是放松,还是紧张,该用户是否会推荐产品给用户。用户使用产品,就犹如和设计师对话,好的设计师处处为用户考虑,用户使用完产品后会很放松甚至兴奋,会迫不及待的推荐产品给其他用户。
    1. 测试计划及用例 Review

    上面讲到,测试团队在软件测试的过程中,要时刻站在客户的角度思考问题,设计测试用例。测试计划及用例审核 Review,其目的就是为了检验测试用例的结构,计划,及每个测试用例的测试点,确保一切从客户出发。

    审核过程中,应该有业务人员,架构师介入,甚至客户介入。

    1. 文档 Review

    文档是软件的一部分,而且文档能够辅助用户使用软件的,也需要严格的质量控制。文档的目的是让人学会使用产品,所以高质量的文档,不仅是一个没有错误的文档,还需要能够快速的帮助用户学会使用软件。下面是高质量文档书写的几点最佳实践:

    1. 能用视频少用图片,能用图片少用字。现在用 Flash 视频教学是非常好流行的一种教学方式,尽量多用一些 Flash 视频的教学方式,如果没有视频,也尽量多一些图片,产品截图等。
    2. 多一些例子,比如 Struts 框架提供了 show case 等一系列例子,教导用户如何开发和使用技巧,这些比纯文字的文档形象直接,效果更是不可同日而语。
    3. 文档中尽量少用缩写,除非是人尽皆知的缩写,如 IBM, EJB 等词语。如果需要使用缩写,需要在一些地方标记出全名。

    敏捷开发质量控制工具

    如上面几个小节介绍的,敏捷开发中的质量控制贯穿整个软件生命周期。包括需求,架构,设计,测试,文档等的质量控制。

    工具支持上,也涵盖了整个生命周期的质量控制,从早期的需求管理工具,到各个阶段的测试工具,到代码检测及重构工具等。由于篇幅关系,在下一篇文章系统介绍整个质量控制过程的工具支持。

    展开全文
  • 敏捷开发之道

    2012-07-22 19:15:41
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程软件一直处于...

            敏捷开发(agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

     

            敏捷开发是全新理论吗?答案莫衷一是。细心的人们可以发现,敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发,这两种在任何一本软件工程教材中都会被提到的方法,在敏捷开发模式中扮演了很重要的角色。再向前追溯,我们还也可见到瀑布式与快速原型法的影子,也许还有更多。

     

            改善,而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华,去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中,我们每两周都会得到一个可以工作的软件,”Fowler介绍,“这种非常短的循环,使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

     

            也许是因为时间关系,Fowler只说出了这些优势中的一部分。允许开发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验,拥有的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。

     

            问题与思考

            然而,我们不得不面对的现实却是,模式与方法的优化并不意味着问题的终结。作为一种开发模式,敏捷开发同样需要面对众多挑战。

     

            大项目的拆分意味着更多子项目的出现,协调这些同步或异步推进的子项目,合理的资源调配都将变得更加复杂。另外,在当前项目和项目组普遍“增容”的情况下,遇到的问题同样成倍增长。人的重要性被提到了更高的高度,而缺乏有效协调手段,减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的同时,也相应引发了几乎同样多的问题。


            敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非常支持这一理论,他采取了"敏捷方式"组建团队:Capital One的"敏捷团队"包括3名业务人员、两名操作人员和5~7名IT人员,其中包括1个业务信息指导(实际上是业务部门和IT部门之间的"翻译者");另外,还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培训,具备相关的技能。

     

            每个团队都有自己的敏捷指导(Bailar聘用了20个敏捷指导),他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段,团队人员密切合作,开发有规律地停顿--在9周开发过程中停顿3~4次,以评估过程及决定需求变更是否必要。在Capital One,大的IT项目会被拆分成多个子项目,安排给各"敏捷团队",这种方式在"敏捷开发"中叫"蜂巢式(swarming)",所有过程由一名项目经理控制。

     

            为了检验这个系统的效果,Bailar将项目拆分,从旧的"瀑布式"开发转变为"并列式"开发,形成了"敏捷开发"所倡导的精干而灵活的开发团队,并将开发阶段分成30天一个周期,进行"冲刺"--每个冲刺始于一个启动会议,到下个冲刺前结束。

     

            在Bailar将其与传统的开发方式做了对比后,他感到非常兴奋--"敏捷开发"使开发时间减少了30%~40%,有时甚至接近50%,提高了交付产品的质量。"不过,有些需求不能用敏捷开发来处理。" Bailar承认,"敏捷开发"也有局限性,比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构中却不能排列出三者优先级的需求。此外,他觉得大型项目或有特殊规则的需求的项目,更适宜采用传统的开发方式。尽管描述需求一直是件困难的事,但经过阵痛之后,需求处理流程会让CIO受益匪浅。

     

            敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则,并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,他们认为:

     

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

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

    •客户合作胜过 合同谈判

    •响应变化胜过 遵循计划

    并提出了以下遵循的原则:

     

    •我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

    •即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

    •经常性地交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。

    •在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

    •围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

    •在团队内部,最具有效果并富有效率的传递信息的方法,就是面对面的交谈。

    •工作的软件是首要的进度度量标准。

    •敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

    •不断地关注优秀的技能和好的设计会增强敏捷能力。

    •简单是最根本的。

    •最好的构架、需求和设计出于自组织团队。

    •每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

    一、敏捷开发方法

     

    (一)说明

    本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法,AgileSoftware Development是一组软件开发方法的总称,包括(Crystal , Extreme Programming , Adaptive software development等等)。敏捷开发方法又称为“轻量级”开发方法。

     

    下面这段话摘自Martin Fowler的一篇文章:

     

    从无到繁重再到敏捷

            多数软件开发仍然是一个显得混乱的活动,即典型的“边写边改”(code and fix)。设计过程充斥着短期的,即时的决定,而无完整的规划。这种模式对小系统开发其实很管用,但是当系统变得越大越复杂时,要想加入新的功能就越来越困难。同时错误故障越来越多,越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段,有时甚至有遥遥无期之感,从而对项目的完成产生严重的影响。

            我们使用这种开发模式已有很长时间了,不过我们实际上也有另外一种选择,那就是“正规方法”(methodology)。这些方法对开发过程有着严格而详尽的规定,以期使软件开发更有可预设性并提高效率,这种思路是借鉴了其他工程领域的实践。

            这些正规方法已存在了很长时间了,但是并没有取得令人瞩目的成功,甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐,要是按照它的要求来,那有做太多的事情需要做,而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法,或Jim HighSmith 所称的“巨型”(monumental)方法。

            作为对这些方法的反叛,在过去几年中出现了一类新方法。尽管它们还没有正式的名称,但是一般被称为“敏捷型”方法。对许多人来说,这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡,使得能以不多的步骤过程获取较满意的结果。

            敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档,对于一项任务,它们通常只要求尽可能少的文档。从许多方面来看,它们更象是“面向源码”(code-oriented)。事实上,它们认为最根本的文档应该是源码。

            但是,我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象,它其实反映的是更深层的特点:

            敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,它们的目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。

            敏捷型方法是“面向人”的(people-oriented)而非“面向过程”的 (process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

            我认为以上两个特点很好的概括了敏捷开发方法的核心思想:适应变化和以人为中心

     

    (二)方法背后的思想

     

    Alistair Cockburn在AgileSoftware Development中讲述了敏捷开发方法背后的思想

     

            人们掌握过程(process)可以分为3个阶段:

    1 following 遵循一个定义好的process

    2 detaching 知道不同process的适用范围,在不同的场合使用不同的process

    3 fluent 不关心是否遵循特定的process,知道在什么情况下采用什么动作

     

            软件开发是一个充满发明和交流的协作性游戏 (cooperative game of invertion and communication)。软件开发的首要目标是生产出软件,遵循特定的过程和模型只是手段,只要传递了足够的信息,手段是次要的。交流的效果要远远重于交流的形式(Effect of communication is more important than the form ofcommunication)。

    一般软件开发有两个目标:1 尽快的生产出软件2 为下一个team或项目做准备,有时这两个目标是矛盾的,我们要在这两个目标之间寻求平衡

     

            在软件开发中,人的因素要远远大于过程和技术。人是有缺陷的:

    1 容易犯错误,因此必须在错误扩散之前找到并改正错误

    2 当觉得可能失去较多的时候,不愿意冒险

    3 重新构造而不愿意重复使用已有的东西

    4 难于坚持一个习惯

     

           针对个人因素的几个建议:

    1 具体的模型较抽象的模型更容易理解

    2 从一个例子开始是容易的

    3 通过观察他人的成果学习

    4 要有足够的不受打扰的时间

    5 分配的工作要与个人意向,能力匹配

    6 不正确的奖励会有坏作用,从长期看个人兴趣比奖励更重要,培养在工作中的自豪感:

    1) pride in work参与工作的自豪感,通常参与一个重要的工作会有自豪感

    2) pride in accomplishment 完成工作的自豪感,长期未完的工作会使士气低落

    3)pride in contribution 为他人贡献的自豪感

    7 鼓励关心其他人的工作和整体的工作

     

            在一个团队之间,交流是最重要的,实践证明面对面的实时的交流是最有效的,对交流的延误会损失信息,白板是最好的交流工具,交流工具的先进并不能提高交流效果。文档的作用是记录和备忘,不能通过文档交流。

     

           敏捷开发方法要避免的过程设计的几个常见错误

    1 对所有的项目使用同一种过程

    2 没有弹性

    3 过于沉重

    4 增加不必要的“必须完成”(“shoulddo” is really should?)

    5 没有经过实践检验

     

            敏捷开发方法过程设计的几个原理:

    1 交互的面对面的交流是代价最小,最迅速的交换信息的方法

    2 超过实际需要的过程是浪费的

    3 大的团队需要重量级方法

    4 处理重大问题的项目需要重量级方法强调

    5 增加反馈和交流可以减少中间产品和文档的需求

    6 轻量级方法更强调理解(understanding),自律(discipline)和技能(skill),重量级方法更强调文档(documentation),过程(process)和正式(formality)

    understanding指整个团队关于项目的全部知识,包括讨论的过程,documentation只能记录其中的一部分

    discipline是指个人主动的完成工作,process指个人根据指令完成工作

    skill指具有良好技能的人可以省略中间的产品,formality指必须按照规定步骤完成工作

     

    7 确定开发中间的瓶径,提高它的效率

    对于瓶径处的工作应该尽量加快,减少重复,(使用更熟练的人,使用更多的人,使用更好的工具,使瓶径处的工作的深入尽量稳定)对于非瓶径处的工作可以多一些重复,在输入还不确定的情况下也可以尽早开始。

     

            这些原理的几个结论:

    1 向一个项目增加人员要花费较大代价(constly),因为原有人员和新人员之间的交流要花费大量时间

    2 团队的规模经常是跳跃的,例子:需要6个熟练的程序员,但是只有4个,于是增加不熟练的程序员,结果团队的大量时间花费在培训不熟练的程序员上面,最后增加到了20个不熟练的程序员。

    3 应该侧重于提高团队的技能而不是扩充团队

    4 对不同的项目使用不同的过程

    5 在适用的条件下,轻量级的方法优于重量级的方法

    6 对不同的项目要裁减过程

     

    敏捷开发方法的原则是“刚刚好”(Light and Sufficient)

     

     

    (三) Crystal

     

    Crystal是Alistair Cockburn提出的一组开发方法,分为CrystalClear,Crystal Yellow, Crystal Orange和Crystal Red分别适用于不同的项目。项目可以按照参加的人员和重要性划分。重要性根据项目中的错误引发的后果分为:

    C Loss of comfort (某些不舒适)

    D Loss of discretionary money (经济损失)

    E Loss of Essential Money (严重经济损失)

    L Life Critical (生命危险)

    一个项目称为C6说明参加人员在6人以下,重要性是C级,D20说明人员在6-20人,重要性是D级。

     

    Crystal Clear适用于 C6,D6项目

    Crystal Yellow适用于C20,D20,E20项目

    Crystal Orange 适用于C40,D40,E40项目

    Crystal Red 适用于 C80,D80,E80项目

     

    Crystal Clear

     

    适用于一个办公室内的一个小组

     

    角色有: sponsor发起人,任务下达者

    Senior Designer-Programmer 高级设计开发人员

    Designer-Programmer 设计开发人员

    User 用户

    其中一个人是项目协调者(Project Coordinator)。Senior Designer-Programmer是关键人员

     

    策略:

    1 软件的开发采用有规则的周期性递增方法,每2-3个月提交(deliver)一个版本

    2 使用里程碑(milestone)跟踪进度(包括delvier和开发期间的重大决定)

    3 自动回归测试(automatedregression test)

    4 用户直接参与

    5 每个release有两个userviewings(用户审核?)

    6 在上一个步骤足够稳定(stableenough to review)时立即开始下一个步骤,尽量并行开发

    7 在每个周期的开始和中间进行产品和过程调整

     

    过程产品(指整个过程产生的所有产品,包括软件和文档)

    1 软件释放顺序(releasesequence)

    2 用户审核的计划

    3 用户案例(usecase)或需求描述

    4 设计框架和必要的说明

    5 界面草图

    6 基本的对象模型

    7 执行代码

    8 migration code

    9 测试用例

    10 用户手册

    11 local matters有项目组决定:

    上述product的摸班

    编码和用户界面的标准

    回归测试的标准和细节

    其他文档

    需要的工具:

    版本控制工具

    白板(最好可打印)

     

     

    Crystal Orange

     

    角色:sponsor 发起人

    business export/usage export 业务专家

    technical facilitator 技术专家

    business analyst/designer 业务分析和设计人员

    project manager 项目管理员

    architect 系统架构人员

    Design Mentor 设计指导人员

    Lead Designer-Programmer 主要设计编码人员、

    Other Designer-Programmer设计编码人员

    UI Designer 用户界面设计人员

    Writer 文档写作人员

    Tester 测试人员

     

    策略:

    同Crystal Clear (周期可以为3-4个月)

    过程产品:

    需求文档

    计划

    状态报告

    用户界面设计文档

    基本对象模型

    外部接口标准

    用户手册

    源代码

    测试用例

    migration code

    local matters 同CrystalClear

     

     

    (四) The Agile Alliance

     

    敏捷联盟是17位不同敏捷开发方法的提倡者共同成立的,目的是推进敏捷开发方法的研究和应用,他们并不要求强制使用某种开发方法,而是提出了敏捷开发的几个核心价值和基本原则:

    core value:

     

    Individuals and interactions over processesand tools

    个人和交流重于过程和工具

    Working software over comprehensivedocumentation

    正在运行的软件本身重于复杂的文档

    Customer collaboration over contractnegotiation

    与客户的沟通和交流重于使用合同约束客户

    Responding to change over following a plan

    对变化的快速响应重于跟随计划

     

    principles

     

    1 最高目标是通过快速的和经常的发布软件满足客户的需要

    2 提交软件的周期为几个星期到几个月

    3 产生正确的软件是衡量进度的首要标准

    4 主动接受需求的改变而不是拒绝

    5 商务人员和开发人员工作在一起

    6 个人必须有动力,要创造环境支持他们的要求,信任他们

    7 最有效的交流方法是面对面的交流

    8 最好的结构,需求和设计来自于自组织的团队(self-organizingteam),允许任何人提出想法和建议

    9 持续改进设计和编码

    10 鼓励正常工作,减少长时间加班

    11 保持简单,减少不必要的部分,认识到简单的设计比复杂的设计更难(simple design is harder to produce)

    12 定期调整过程,获得更高效率

     

     

    (五) Extreme Programming

     

            Extreme Programming(XP,极限编程) 是一种轻量级的软件开发方法,它使用快速的反馈,大量而迅速的交流,经过保证的测试来最大限度的满足用户的需求。XP强调用户满意,开发人员可以对需求的变化作出快速的反应。XP强调team work。项目管理者,用户,开发人员都处于同一个项目中,他们之间的关系不是对立的,而是互相协作的,具有共同的目标:提交正确的软件。XP强调4个因素:

    交流(communication),XP要求程序员之间以及和用户之间有大量而迅速的交流

    简单(simplicity),XP要求设计和实现简单和干净

    反馈(feedback)通过测试得到反馈,尽快提交软件并根据反馈修改

    勇气(courage)。勇敢的面对需求和技术上的变化

     

    XP特别适用于需求经常改变的领域,客户可能并系统的功能并没有清晰的认识,可能系统的需求经常需要变动。

    XP也适用于风险比较高的项目,当开发人员面对一个新的领域或技术时,XP可以帮助减低风险

    XP适用于小的项目(人员上),人员在2-12人之间,XP不适用于人员太多的项目,事实上,在需求经常变化或风险比较高的项目中,少量而有效的XP开发人员效率要远远高于大量的开发人员。

     

    下面是XP的开发流程

     

     

    XP的原则和实践:

     

    1 Planning:

     

    1)user stories。

    User stories类似use case, 描述用户所见的系统功能,但避免使用大量的文档,user stories由用户编写(不仅限于描述用户界面)。User stories使用用户的语言编写,不使用技术性的语言,每个user stories限于几句话。User stories用于在release plan会议上对开发时间进行评估,也用于产生验收测试(acceptance test),必须使用可以自动进行的验收测试保证软件的正确性。User stories与传统的用户需求的区别在于详细的程度,user stories并不会确定需求的每个细节,它只是用来简单的描述系统功能,供开发人员进行估计开发进度,在开发过程中开发人员和用户会不断的交流以讨论细节问题。User story应该专注于功能,不应该过分注重用户界面等细节。一般一个user storiy在1-3周的时间完成,如果估计超过3周,说明user story太大了,需要细分。

     

    2)release plan.

    召开一个 release plan会议,产生release plan。Release plan将用于指定每个iteration的计划。开发人员对每个user story估计开发时间(在不被打断,无其他工作情况下的开发时间,包括测试),用户对user stories给出优先级,release plan会议并不制订每个iteration的计划。Release plan要用户,开发人员和管理者都同意,在完成功能范围(scope),使用资源(resource),时间(time)和质量(quality)上达成一致(一般质量是不能改变的)

     

    3) small release

    often and small release是XP的一个原则,每个release完成一些用户有意义的功能集合,尽快的提交给用户以获得反馈,及时调整,提交的越晚,调整越困难。

    4)project velocity

    团队在开发过程中要收集数据,以便于对自己的开发速度进行评估,用于以后的releazse plan

     

    5)iteration

    每个small release的周期称为iteration,每个iteration约为1-3周,在一个项目中保持每个iteration的时间相等,不要超前制定计划,每个iteration的计划在iteration的开始时制定。这样能够更灵活的应付变化。不要急于完成本次iteration没有包括的功能。要注重每个iteration的时间限制,当团队觉得不能按时完成iteration时,召开一次iteration plan会议,重新评估,减少一些user stories。

     

    下面是iteration的图示:

     

     

     

    6)iteration plan

    在每个 iteration开始的时候召开会议,从release plan中选择还没有实现的用户最迫切需要的user stories。上一个iteration中没有通过验收测试的功能也要在这个iteration中实现。可以根据上一个iteration的实践调整团队速度。User stories和失败的测试被分解成programming task,task使用技术语言编写,作为iteration plan的详细描述。程序员主动领取task并估计完成时间,每个task应该在1-3天内完成,超过3天的task应该被细分。如果整个团队需要的时间多于或少于规定的iteration时间,调整user stories。

     

    7)move people around

    不要使每个开发人员局限于一项工作,不要使某项工作依赖于一个开发人员,增加知识共享,减少信息孤岛,多进行交流和培训。当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的,鼓励开发人员在不同iteration中开发不同的模块。

     

    8) stand-up meeting

    每天工作开始之前,开5-10分钟的stand-up会议(站立会议),站立的目的是为了强迫节省时间,会议的目的是交流,提出存在的问题,但不要在会议上解决问题。开一个所有人员参加的短会比多个个别人员参加的会议要高效。在会议上提出的问题可以由少数人讨论解决,这个少数人参加的会议如果涉及到代码,可以在计算机前讨论。

     

    9) fix XP when it breaks

    XP并不是一成不变的,当团队觉得需要修改的时候,可以根据自己的情况进行修改,任何修改都要经过整个团队的讨论和达成一致

     

    2 Designing

     

    1) Simplicity

    保持简单的设计,在完成同样的功能的情况下,选择简单的设计,不要急于设计没有计划的功能,应该认识到:keeping a design simple is hard work

     

    2)system metaphor

    使用统一的术语描述系统,在用户,管理者和开发人员之间使用统一的术语。这将使交流清晰。

     

    3)CRC card

    使用CRC(Class, Responsibilities, and Collaboration) card进行系统设计,鼓励更多的人参加设计。每个CRC卡片表示系统中一个对象,写上对象的名字,责任和每个责任需要交互的其他对象。可以模拟对象之间的交互。CRC卡片是易于理解的,但是是非正式的,如果需要正式的文档,要将卡片转换为相应的文档。

     

    4) spike solution

    使用spike solution减低风险,当遇到技术难题或设计问题时,使用简单的程序进行测试,找出问题,在不同的解决方法之间进行评估。在早期进行实验可以有效的降低风险。

     

    5)never add functionearly

    不要过早的设计没有计划的功能,在一个需求经常变化的环境中,过早的设计经常是没有用的。

     

    6)refactoringwheneverand wherever

    XP鼓励对设计和代码经常进行重构(Refactoring),目的是去除冗余,提高质量,保持设计简单。重构必须以完全测试为检验条件

     

     

    3 Coding

     

    1) customer is alaways available

    用户是项目组的成员之一,用户的参加贯穿整个开发过程,用户与开发人员之间的交流是重要的

     

    2) coding standard

    使用统一的编码标准,这是保持代码整洁和共享代码的基础

     

    3)coding unit testfirst

    test first是XP的一个特点,在编写代码之前先编写单元测试代码,单元测试代码和代码由同一个程序员完成。先编写测试代码可以使程序员更好的理解需求,避免直接编码造成的理解偏差,对需求的不清晰,可以在编写测试代码时就发现。测试代码也是检验程序是否完成的标准。编码工作应该是以下工作的循环:

    1 编写测试代码

    2 运行测试程序,确认失败

    3 编写实现这个测试程序要求功能的代码,不需要实现其他的功能,只需要实现刚刚满足测试程序的功能

    4 运行测试程序,确认成功

    实践证明,test first方式需要的编码实践少于先编码,后写测试代码

     

    4) Pair Programming

    Pair programming是XP的特色,它要求两个程序员在一台计算机上同时进行编程工作。共用鼠标和键盘,通常一个人进行战略上的思考,程序架构和函数,类之间的关系,一个人进行输入和战术上的思考,完成函数和类。两个人可以经常交换角色。Pair programming需要一段时间学习和适应,实践证明pair programming并不消耗更多的时间(人*小时),但是代码的质量得到很大的提高。(避免将两个新手放在一个pair中)

     

    5)sequentialintegration

    要保证源代码库的状态是可标识的,同一时间,只允许一个pair的程序进行整和和测试,这样可以缩小问题产生的范围。不同的pair可以在自己的机器上随时进行整和和测试.

     

    6) integrate often

    只要有可能就进行代码整合,周期可以在几个小时,最好不要超过一天。经常的整合可以避免错误的积累,可以增加可重用的代码。在一个pair认为适当的时候并通过了所有的unit test,就可以进行整合,整合后的代码必须通过测试。同一时间,只允许一个pair进行整合。(整合失败是不是要退回原有状态,供其他pair整合??)

     

    7) 共同拥有代码

    鼓励每个人对项目中的任何人提出新的想法,任何开发人员对项目中的任何代码都可以进行增加功能,改正错误和重构。没有代码或开发人员成为瓶颈。(我的想法:这确实很难理解,但是这确实是我梦想的目标)。为了达到这个目标,任何的代码都必须有相应的测试代码,任何代码的修改必须100%通过测试。必须加强开发人员的交流和知识共享,必须坚持统一编码标准。Pair programming可以经常交换伙伴。

     

    8)优化工作放在最后

    先使系统能够正常工作,不要猜测系统的瓶颈,要实际测量

     

    9)NO overtime

    不要长时间的加班,大多数加班并不能挽回已有的延迟,连续超过两个星期的加班说明有问题存在。向一个已经延迟的项目填加人员也不是一个好的选择。

     

     

     

     

    4Testing

     

    1)所有的代码都有单元测试

    单元测试是XP的基石,XP中的单元测试应该是可以自动进行的,所以可以很快的进行所有的单元测试,单元测试应该在编码之前创建。单元测试的代码和代码一起release,没有单元测试的代码不能够release。使用自动单元测试可以系统整合时节省大量的发现错误和改正的时间。单元测试越完善,节省的时间越多。对面向对象的编程来说,应该对每个类都有单元测试。完善的单元测试也是共同拥有代码的保证。单元测试也是可以经常重构的保证,每次重构后的代码都要重新进行测试

    (这里的unit test好象不只限于测试某个模块的功能???,应该可以测试整合起来的整个系统,这样才能保证整合的正确性。)

     

    2)代码在release前必须通过所有的单元测试

     

    3) 发现bug后,首先增加测试

    在实际运行中发现bug,首先增加acceptance test,然后增加unit test,在增加完测试后在查找和修改代码,增加的测试保证同样的错误不会再出现

     

    4) acceptance test

    acceptance test根据userstories在iteration plan会议上创建,它也应该可以自动运行以便可以经常运行。User stories是否完成是以是否通过acceptance test为检验标准。

     

     

    XP中的角色:

     

    1 customer 用户

    在XP中,用户是项目组的一部分,用户负责编写use stories,确定优先级,和开发人员讨论需求,编写accept test,运行accept test,用户驱动iteration(release plan, iteration plan)

     

    2 开发人员

    与用户讨论user stories,估计开发时间,将user stories细化成programming task

    编写unit test

    编码

    进行重构

    整合及测试,保证100通过

     

    3 manager

    负责对外联系,组织团队,获取必要的资源,管理团队

     

    4 tracker

    跟踪release plan/iteration plan/acceptance test

     

    5 coach

    起顾问指导作用,mentor, monitor and help

    A Coach is respected, but also respectful.They’re willing to talk, but also willing to listen. They let the team explore,but provide a guard-rail in case of danger.

    监督进展,确保过程和规则,必要时改变过程,帮助解决问题,也可以参加pair programming。

     

     

    二、敏捷开发的设计原则

     

    关于敏捷开发的设计原则:

    单一职责原则SRP:Single Responsibility Principle

    开放封闭原则OCP:Open-Close Principle

    Liskov替换原则LSP:LiskovSubstitution Principle

    依赖倒置原则DIP:Dependency Invertion Principle

    接口隔离原则ISP:Interface Separate Principle

    关于包的设计原则:

    重用发布等价原则REP:Reuse Equivalence Principle

    共同重用原则CRP:Common Resue Principle

    共同封闭原则CCP:Common Close Principle

    无环依赖原则ADP:Acyclic Dependency Principle

    稳定依赖原则SDP:Stabilization Dependency Principle

    稳定性度量公式:I=Ce/(Ca+Ce) (I:不稳定度,Ce:输入耦合度,Ca:输出耦合度)

    I取值范围在【0,1】,I=0表示具有最大稳定度;iI=1标识具有最大不稳定度

    稳定抽象原则SAP:Stabilization Abstract Principle

     

     

     

    GOF说--基于对象组合的设计会有更多的对象(而有较少的类)。

    如果单纯的看这里,你会明白似乎类较少符合面向对象的逻辑。

    但是且慢,我们知道面向对象有一条原则叫单一职责原则--SRP。

    这样好像类多又是面向对象思想的体现。

    其实最重要的是GOF中的这句话--且系统的行为将依赖对象间的关系而不是被定义在某个类中。

    所以类的多少并不是问题的关键,是否职责单一也不是大问题,

    最重要的是你现在的那些职责是都多少是不能被别的职责通过某种方式所代替的。

    在BOB大叔那里定义职责是变化的原因,因此就可以认为这些变化的原因应该是不可代替的,

    也可以说你不能由这个原因推导出别的原因。

    只要这个原因间可以做到相互关联,那么你就可以把由于这些变化而引起变化的类组合起来,

    而不是把他们规定在新的类中。

     

    开放封闭原则OCP:Open-Close Principle

     

    一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。

     

    因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。

     

    该原则同样适合于非面向对象设计的方法,是软件工程设计方法的重要原则之一。

     

    我们以收音机的例子为例,讲述面向对象的开闭原则。

     

    我们收听节目时需要打开收音机电源,对准电台频率和进行音量调节。

     

    但是对于不同的收音机,实现这三个步骤的细节往往有所不同。

     

    比如自动收缩电台的收音机和按钮式收缩在操作细节上并不相同。

     

    因此,我们不太可能针对每种不同类型的收音机通过一个收音机类来实现(通过重载)这些不同的操作方式。

     

    但是我们可以定义一个收音机接口,提供开机、关机、增加频率、降低频率、增加音量、降低音量六个抽象方法。

     

    不同的收音机继承并实现这六个抽象方法。

     

    这样新增收音机类型不会影响其它原有的收音机类型,收音机类型扩展极为方便。

     

    此外,已存在的收音机类型在修改其操作方法时也不会影响到其它类型的收音机。

    图1是一个应用OCP生成的收音机类图的例子:

     

    Liskov替换原则LSP:LiskovSubstitution Principle

     

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

     

    我们以学生为例,夜校生为学生的子类,因此在任何学生可以出现的地方,夜校生均可出现。

     

    这个例子有些牵强,

     

    一个能够反映这个原则的例子时圆和椭圆,圆是椭圆的一个特殊子类。

     

    因此任何出现椭圆的地方,圆均可以出现。但反过来就可能行不通。

     

      运用替换原则时,我们尽量把类B设计为抽象类或者接口,

     

    让C类继承类B(接口B)并实现操作A和操作B,

     

    运行时,类C实例替换B,这样我们即可进行新类的扩展(继承类B或接口B),

     

    同时无须对类A进行修改。

     

    依赖倒置原则DIP:Dependency Invertion Principle

     

    在进行业务设计时,与特定业务有关的依赖关系应该尽量依赖接口和抽象类,而不是依赖于具体类。

     

    具体类只负责相关业务的实现,修改具体类不影响与特定业务有关的依赖关系。

     

    在结构化设计中,我们可以看到底层的模块是对高层抽象模块的实现(高层抽象模块通过调用底层模块),

     

    这说明,抽象的模块要依赖具体实现相关的模块,

     

    底层模块的具体实现发生变动时将会严重影响高层抽象的模块,显然这是结构化方法的一个"硬伤"。

     

     

      面向对象方法的依赖关系刚好相反,具体实现类依赖于抽象类和接口

     

      为此,我们在进行业务设计时,应尽量在接口或抽象类中定义业务方法的原型,

     

    并通过具体的实现类(子类)来实现该业务方法,业务方法内容的修改将不会影响到运行时业务方法的调用

     

    接口隔离原则ISP:Interface Separate Principle

     

    采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。

     

     

      ISP原则是另外一个支持诸如COM等组件化的使能技术。

     

    缺少ISP,组件、类的可用性和移植性将大打折扣。

     

    这个原则的本质相当简单。如果你拥有一个针对多个客户的类,

     

    为每一个客户创建特定业务接口,然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

     

    以下展示了一个拥有多个客户的类。

     

    它通过一个巨大的接口来服务所有的客户。

     

    只要针对客户A的方法发生改变,客户B和客户C就会受到影响。

     

    因此可能需要进行重新编译和发布。这是一种不幸的做法。

     

    所展示的技术。每个特定客户所需的方法被置于特定的接口中,这些接口被Service类所继承并实现。

     

    如果针对客户A的方法发生改变,客户B和客户C并不会受到任何影响,也不需要进行再次编译和重新发布。

     

    三、敏捷开发技术在电子商务软件中的应用

     

      第一章背景介绍

     

      1.1 电子商务背景

     

      随着企业信息化的不断进步,电子商务在中国也越来越得到更多的认可,电子商务的应用也越来越多,但是很多企业对电子商务的概念和应用还不是很清楚,行业内对电子商务的研究模式和实施方法也存在很多问题。因此很多企业在实施电子商务系统的过程中都处在探索和摸索当中,对于项目开发方来说也有着极大的风险性和挑战性。

     

      1.2 电子商务软件开发存在的问题

     

      由于电子商务软件开发存在很大的风险性,而且电子商务的应用也出在不断摸索当中,没有很多成熟的模式可以参考,所以没有实践的指导可能会导致的项目噩梦。缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。更长时间的工作却生产出更加低劣的软件产品,也使得开发人员感到沮丧。我们希望这些方法这次还会有效,从而消除我们的恐惧。然而,项目并没有简单到使用一些约束和人为制品就能够可靠地防止错误的地步。当连续地犯错误时,我们会对错误进行诊断,并在过程中增加更多的约束和人为制品来防止以后重犯这样的错误。一个大而笨重的过程会产生它本来企图去解决的问题。它降低了团队的开发效率,使得进度延期,预算超支。它降低了团队的响应能力,使得团队经常创建错误的产品。

     

      1.3 敏捷开发技术概述

     

      敏捷式开发采用适应性方法,而传统的软件工程学采用的是预测性方法。敏捷式开发是以人为主的,而传统的工程学是以过程为主的。

     

      1.4 敏捷开发的现实意义

     

      适应性和预测性的区别存在于软件工程学对软件开发过程的描述中。在传统的工程学里,核心的概念就是把设计和构建这两个过程分开进行。在软件开发的过程中,我们很难想象,如何真正把设计和编程完全区分过来。软件工程学领域,所有在这里从事工作的人员,都把设计的过程想象成用图表、图象的方式来描述结果的过程。还有一个更重要的问题就是说,软件本身的需求是在变化的。一个项目在开发过程中需求会出现变化,需求的变化从根本上推翻了工程学方法所建立的一个基础。当工程学的人尽量减少或者控制系统将来发生变化的可能,他越这样做问题就越容易出现。既然我们没办法避免变化的发生,那么我们就想找到一种新的方法能够更有效地适应这种变化现象。这也就是敏捷式开发方法所要达到的效果。

     

      第二章敏捷开发技术的应用

     

      2.1 敏捷开发技术的几种主要类型

     

    1.XP(Extreme Programming -- 极限编程

     

    2.Cockburn的水晶系列方法

     

    3.开放式源码

     

    4.Highsmith的适应性软件开发方法〔ASD〕

     

       2.2 敏捷开发技术的特点和优势

     

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

     

      人是获得成功的最为重要的因素。如果团队中没有优秀的成员,那么就是使用好的过程也不能从失败中挽救项目,但是,不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作,那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境,然后期望团队自动凝聚在一起的错误。相反,应该首先致力于构建团队,然后再让团队基于需要来配置环境。

     

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

     

      没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档,来对系统及其设计决策的依据进行描述。然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言,会造成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的,但是代码是惟一没有二义性的信息源。在团队成员的头脑中,保存着时常变化的系统的脉络图(road map)。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。

     

      3.客户合作胜过合同谈判

     

      不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述,然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时,失败是惨重的。告诉开发团队想要的东西,然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来,这对于公司的管理者来说是具有诱惑力的。然而,这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间,也会出现整个功能块被减掉,而加进来另外一些功能块。然而,合同和项目都经受住了这些变更,并获得成功。成功的关键在于和客户之间真诚的协作,并且合同指导了这种协作,而不是试图去规定项目范围的细节和固定成本下的进度。

     

      4.响应变化胜过遵循计划

     

      响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时,应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。

     

      2.3 敏捷开发技术的12个原则

     

    1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

     

    2.即使到了开发的后期,也欢迎改变需求。

     

    3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好

     

    4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

     

    5.围绕被激励起来的个人来构建项目。

     

    6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。

     

    7.工作的软件是首要的进度度量标准。

     

    8.敏捷过程提倡可持续的开发速度。

     

    9.不断地关注优秀的技能和好的设计会增强敏捷能力。

     

    10.简单使未完成的工作最大化。

     

    11.最好的构架、需求和设计出自于自组织的团队。

     

    12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。

     

      2.4 敏捷开发技术的适用范围

     

    1.项目团队的人数不能太多

     

    2.项目经常发生变更

     

    3.高风险的项目实施

     

    4.开发人员可以参与决策

     

      第三章敏捷开发技术在电子商务软件的实际应用案例

     

      3.1 案例说明:钢铁贸易企业的网上期货订货系统开发实施

     

      项目背景:国内某大型国有钢铁贸易企业,其业务形式大部分采用期货订货,客户群也比较广泛,订货时间相对比较稳定,一般集中在月底的10天左右。该企业原来开发了一套适合自己企业运作的贸易企业ERP系统,但是仅仅是在公司内部使用,功能也很有限,不能够很好的和客户进行信息交流,往往客户在集中订货的时候,因为订货量巨大,而且时间集中,所以造成该企业的业务人员忙的团团转,而且经常会发生排队订货的现象,同时由于是期货订货,所以该企业还得向上游供应商订货,这样一来一去,给工作带来极大的不便,也容易造成混乱和漏洞。

     

      因此,介于用户这样的情况,需要开发一套网上期货订货系统,将订货的整个环节都打通,真正实现24小时订货。减少人工干预,通过和几个系统之间的集成,做到实时的信息流通。但是这样一个系统对于该企业来说,毕竟是第一回,国内也没有相关成熟的案例和模型,所以实施存在极大的风险性。而且其他同行业的竞争对手也在着手打造这样的一个系统,所以尽早建立网上订货系统,对于提高顾客的忠诚度和满意度都是大有裨益的,所以对工期的要求也非常严格。

     

      根据以上情况,决定采用敏捷开发技术来实施这个项目。

     

      3.2 项目组织机构

     

      建立联合实施团队,由电子商务公司的项目实施人员和客户方的关键用户一起构成,统一受客户方的常务副总指挥。

     

      工作方式:在客户现场办公,在调研的同时做需求,根据系统架构和功能划分,边做设计边做开发。

     

      沟通方式:每天下班前半个小时,所有项目组成员必须座在一起沟通交流,对每天的工作进行总结和经验交流。每周召开一次推进和培训会议,在不断的开发过程中进行对用户的业务知识,系统知识,和操作的培训,为将来系统的运行维护打下更好的基础。

     

      3.3 项目实施过程

     

      第一轮循环实施周期两个月,不但搭建了整个应用的整体框架,还实现了两大品种的单向期货订货流程。

     

      第二轮循环实施周期两个月,打通了向供应商的期货订货环节,并且实现了另外两个品种的订货。同时逐步将前期做好的系统向用户做推广使用,在不断完善的过程中,对本阶段的项目开发实施做修正。

     

      第三轮循环实施周期三个月。由开发人员和客户方的关键用户对期货订货系统进行完善和优化。

     

      3.4 项目实施效果

     

    1. 客户方由于实施了该项目,给订货用户和公司业务员带来很大的便利,效率大大提高,再也没有排队订货的状况,再也没有业务员通宵达旦的处理订货需求,再也不会和供应商之间发生信息失真的现象。系统的快速实施和推进,使得客户对该系统也越来越依赖,同时该公司的销售业绩也率攀新高。

     

    2.由于采用了敏捷开发技术,极大的降低了开发成本,大大提高了开发的效率。尽管在整个项目实施过程中存在大量的变更和修正,但是这样的开发方式可以很有效的避免带来更多负面的扯皮现象。

     

    3.因为项目 成员由高水平的开发人员参加,所以对客户的业务理解非常深入,在实际的项目开发当中,不但承担了具体开发的工作,还向客户方提出很多很好的建议改进措施,以便业务更加优化,操作更加顺畅。一方面,客户方从中收益,另外一方面,开发人员的能力也得到了极大的提高。

     

      第四章敏捷开发技术在电子商务软件的推广

     

    1. 电子商务软件实施的高风险性

     

    软件开发行业目前同时存在两种情况,它既是一个非常成功的又是具有很多问题的行业。

     

    2. 在跨平台系统的移植上的应用

     

    电子商务系统经常会出现跨平台的移植。重要的一点就是从功能角度讲,移植前后是否一致。一些敏捷开发中的最佳实践也是可以使用的,比如你可以把所有的需求以测试的方式提炼出来。很多项目都是使用这种方式而且非常成功。而且使用这种叠盖式方式,也能够从项目进程的角度看移植进程有多快。

     

    3. 在电子商务软件外包公司的应用

     

    软件外包是非常普遍的。在实践中发现敏捷式开发对外包也是非常有效的方法。实践中敏捷式开发比一般的开发方式估算的方法更快,而且用的人要少一些。

     

      希望中国更多的软件公司可以采用敏捷开发技术,使我们的软件产业能够得到更加快速的提高和发展!(作者:徐祎 就职于东方钢铁电子商务有限公司,职务为首席项目经理。目前就读上海交通大学MBA班)

     

     

    四、敏捷开发常用工具

     

    工欲擅其事,必先利其器,能利用工具是人与动物的最大区别。然而,大多数商业化工具价格不菲,已经加入WTO好几年了,再用盗版会给企业带来很大的不确定性,并且盗版用多了,往往会失去一种程序员的自豪感,丢掉一种文化。经过几个月的摸索,本着以下原则,偶选择了一些适合中小企业开发的工具,当作自己的工具箱:

    (1)适用于中小型企业,中小型项目(<500万),功能适度

     

    (2)易用性好,具备必要的文档

     

    (3)免费或低价

     

    基于这些工具,慢慢形成了一套敏捷开发过程。

     

    (一)、工具简介

     

    下面简单介绍这些工具,这些工具有些偶已经有相当的使用经验,有些正在使用,有些只是刚选定。除直接用于.net开发的工具中外,还包括一些开发相关的软件设计、项目管理工具。偶的主要开发经验是Web开发,桌面开发和原型开发,对Mobile开发不熟悉,也就没这方面的推荐了。

     

    1,运行平台

     

    常用的也就.net framework 1.1, 2.0, 和mono了,都是免费的。从功能、性能及安装基础来讲,自然.net framework要优于mono了。mono是开源的,.net framework类库可以反编译,从透明的角度讲两者都差不多。如果你想在非windows平台上开发,或者想研究运行时的实现,可以研究mono,否则还是用.net framework吧。

     

    2,服务器

     

    我用过的也就IIS5.0,IIS6.0,Apache加一个mod,还有mono的xsp,这也没啥好比较的,自然首选IIS6.0了。不过IIS虽然免费,但是至少得windows server版本才运行得爽,至少得花几千元。XP上的IIS很不爽,据说也能装全版IIS6.0,不过还是得折腾。开发用的话,用Apache加一个. net的mod,或者mono的xsp,还是挺好用的。Apache的缺点是对新版.net framework的支持较IIS6.0滞后。

     

    3,IDE

     

    tnnd,这个选择空间也很小。首选自然是VS2003或2005,如果VS 2005速成版将来免费的话,偶就选定这个了,或者选价格并不算高的VS 2005 专业版。可恶速成版、专业版中没单元测试,在这里BS微软10000遍。坚决抵制VSTS版!

     

    其它可选的有SharpDevelop和mono develop。对于不开发Web程序的初学者来说,用SharpDevelop其实也挺不错的,集成的Nant,NDoc,NUnit都是很有用的工具。SharpDevelop没断点调试功能,但熟用NUnit的话可以弥补这一不足。如果对类库理解得比较深入的话,采用SharpDevelop,生产力其实也挺高的――即使是进行Web开发。SharpDevelop的缺点之一是暂时没重构功能,在下一个版本里会有。缺点之二是内存占用比较大,还有性能比VS低得多,大项目,大程序可能不爽。我测试过,用SharpDevelop打开一个大于3M的C#源文件(嘿嘿!是csgl还是tao的,忘了),挂了;用VS 2003打开大概要花几十秒。

     

    btw,我个人认为其实就用记事本写中小型(<3000行)的C#程序,效率其实也挺高的,这时候会更加注意类的设计,思路会更清晰一些,当然,速度会慢一些。

     

    4,类库和文档

     

    类库是.net平台的资产。目前.net下成熟的类库比较少,和java比,最大的不足就是这里了。最常用的类库当然是.net framework了,其它各方面的类库在网上都能搜索到一些。类库的关键资产要素是dll和文档。看文档要看一手资料,第一手资料就是源代码或反编译过来的代码,然后就是各类的原始文档,一般是chm格式的。如果看源代码习惯的话,效率会很高,并且,建议用反编译工具看代码,不建议直接看源文件,原因其一是反编译工具提供了很多有用的附加功能,其二是反编译的代码比源文件更真实。常用的反编译工具是Reflector。

     

    .net下的文档是爽死了,比javadoc的pp多了。因此在写代码的时候应该注意,多写///注释,然后用Ndoc自动生成chm文档,多爽呀。

     

    很多开源项目提供源代码和少量的文档,但它的源代码中有大量的///注释,可用NDoc自动生成chm文档。即使没有///注释,采用NDoc生成文档也是很值的。

     

    5,数据库

     

    MS SQL Server Express版应该是免费的,但标准版和企业版价格还是不低的,还是用开源的好。对功能有要求就用PostgreSql,没要求就用MySql。偶现在是GIS项目用PostgreSql,一般项目用MySql。数据库管理用EMS MySQL Manager Lite和EMS PostgreSql Manager Lite,免费,好用,界面很豪华,性能还行。

     

    6,设计与建模

     

    偶选定的UML建模工具是JUDE,2M大,免费但不开源,比ArgoUML功能多、好用。比Visio 的UML功能不知道强大多少倍,比Together也好用。缺点就是只是建模工具,和代码不同步。另一个缺点就是不能自动生成文档。不过偶喜欢这样的工具,强大,体积小,灵活,方便。并且偶觉得它在设计时用就行了,具体的类的文档用NDoc生成。JUDE是基于java的,得安装java虚拟机。好像它跨平台也不怎么样,我在linux下没运行成功过。

     

    开源或免费的数据库建模工具试过很多,感觉都不成熟不好用,最后选择了一个商业软件――CASE Studio 2,价格100-300美元,功能很实用,支持很多数据库,生成的文档也很pp。

     

    7,敏捷开发工具

     

    NUnit――单元测试。

     

    NAnt――build工具。前面已经提及。

     

    NDoc――文档生成。前面已经提及。

     

    CruiseControl.Net ――持续集成,暂时还没用过。

     

    NUnit,NAnt,NDoc用的好的话,感觉非常爽,写程序会有艺术家的感觉。

     

    8,团队协作工具

     

    版本管理:CVS和SVN,推荐SVN。客户端推荐用TortoiseSVN――非常可爱的小乌龟。

     

    Bug管理:偶选用的是BugTracker.NET,简单,用ASP.Net写的,小项目够用了。

     

    需求管理、项目管理、日程、经费计算与管理:还是在用Word、Outlook、Excel。要免费的话可用永中Office试用版,一样好用。

     

    (二)、优势

     

    1,性价比高。对于10人规模的团队,看看软件成本:

     

    运行平台:.net framework 1.1或2.0,免费

     

    服务器:1套windows 2003 server版,数千元

     

    IDE:1套VS 标准版或专业版,数千元,其它用express版就行了

     

    类库和文档:免费

     

    数据库:免费。用商业数据库,让客户掏钱。

     

    设计与建模:1套CASE Studio 2就行了,数千元

     

    敏捷开发工具:免费

     

    团队协作工具:1套MS Office(带Visio的)就行了,数千元,其它人用永中。

     

     

     

    整个下来,不足20000元。

     

    2,易用性好

     

    反正我的感觉是和商业软件差不多或者稍差

     

    3,易扩展

     

    上面工具大部分是开源的,并且很多工具之间协作性比较好,这样可以用来定制适合自己的生产线。老外的那一套生产线,比如RUP,MSF及其相关工具,除价格贵外,其灵活性也不高,别人的生产线不一定适合自己用。这时上面工具的优势就出来了。

     

    (三)、搭建软件生产线

     

    流程1:项目管理流程

     

    用Office管理需求。用SVN进行源代码管理和文档管理,BugTracker.NET进行 Bug管理和事务管理。尽量将程序、文件、文档的维护自动化。

     

    流程2:开发管理流程

     

    开发过程中所维护的文件越少越好。偶觉得应该尽量少用 UML图写文档,只写最关键的部分。类的文档最好由NDoc直接生成。偶用UML工具的时间很少。写代码的过程就是类设计过程。不妨比较这两个流程:(1)用例分析->采用UML工具设计类->由UML工具生成代码或撰写代码->重构代码,自动更新UML文档。(2)用例分析- >撰写代码->重构代码。第一个流程只有一个优势,就是人对图形的理解比对代码的理解更加直观,但是多了很对累赘工作。第二个流程少了很多步骤,并且可以随时根据代码逆向工程出类图出来,

     

    我还是喜欢以代码为基础的流程。撰写代码也可分为2个过程,第一个过程是写出一个代码框架,所有的方法都是UNDO,写出属性,接口,写出///文档。这应该是设计过程。这个过程基本上只产生、维护源文件。类图可以通过visio逆向工程,类设计文档可以通过NDoc自动生成,并且提供了一个测试基础,可以根据这个测试基础写测试代码了。测试代码最好也只写个框架,但是要写好///注释,然后生成测试文档。这应该是设计过程。第二个过程是实现过程,把类文档和代码框架提交给相关人,实现、测试、重构......一切都自动进行......整个过程中只有一份东西,就是源代码,开发过程中的交付件应该都从源代码中自动生成。

     

    数据库脚本和文档用CASE Studio 2维护。最后提交、上线、验收都很好办,所要的东西biaji一下子都出来了。要申报著作权直接从源代码和chm文档中弄一部分出来就够了。

     

    开发的核心是源代码,所有文档应该体现在源代码的结构、关系和注释中。控制整个开发流程的核心工具是Nant。要是能把用例分析过程体现在源代码中就好了!


    展开全文
  • 现在许多开发团队在学习敏捷开发,根据调查,2018年有...如果你的团队已经在使用敏捷开发,或者在 2019 年计划采用敏捷方法,以下几个免费项目管理工具,也许会有至少一款正是你所要找寻的。 1、MyCollab MyC...
  • 敏捷是一个很流行的一个词语,但是在敏捷里面,包括很多团队也是刚开始用Scrum,怎么让质量成为敏捷的一个助力而不是拖累,这个是我主要想谈的。 关于质量的定义,我前不久接触到一个文章,里面有一个图讲到质量的...
  • 敏捷开发

    2011-12-22 18:52:50
    敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程软件一直处于...
  • 跟微软学敏捷开发

    2012-06-30 23:53:12
    自2001年17位软件开发领域的领军人物 聚集在美国犹他州的滑雪胜地雪鸟雪场共同发布《敏捷宣言》开始,敏捷开发作为一种全新的软件开发管理模式和价值观开始在众多软件开发人员和团队推广。经过8年多的...
  • 敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。简言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程软件一直处于...
  • 去年学习软件工程教材,初识敏捷开发。目前所在的团队,也是使用敏捷开发方式。今天读了这篇文章,对于这段时间的效率有所警醒。其次,个人认同文章的用户故事,结对编程思想。 文章援引:...
  • Scrum开发的步骤及准备Scrum敏捷开发的关键字就是增量、迭代,他更重视项目团队之间的现场沟通,不向传统瀑布式开发那样需要万事具备,才开始开发,Scrum在大方向和小故事点确认好了后,团队就可以开动了。...
  • 2009-09-08 作者:Jack Vaughan 来源:ITPUB敏捷开发的潮流并不是由敏捷工具来推动的。因为你可以仅使用命令行接口、单元测试工具和需求卡片来展开敏捷开发。但近年来,为了更好地支持敏捷开 发,敏捷工具也有了很...
  • DAD 方法在IBM Rational的真实运用,除了支撑团队的敏捷性以外,对于项目的透明度,如风险预估和控制, 架构的原型需求,对于构建过程的迭代管理、测试管理、变更管理等是如何融入到开发和测试流程的呢?...
1 2 3 4 5 ... 20
收藏数 407
精华内容 162
关键字:

敏捷开发中story定制