敏捷开发 跟踪长期的项目_项目经理在敏捷开发中的作用敏捷开发 - CSDN
  • 今天开一篇敏捷开发相关的文章,说说我对敏捷的理解和实践。  Scrum 是什么?  Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期...

         前两天,有群里的朋友在管理团队开发过程中有一些敏捷方面的疑问,类似如何评估工作量、如何高效的进行早会等问题。今天开一篇敏捷开发相关的文章,说说我对敏捷的理解和实践。

         Scrum 是什么?

         Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周,在互联网开发领域,像类似app的开发,可以缩短到一周。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。

         接下来我们以实际的项目为例,详细阐述敏捷开发的运用。

    1.首先,项目开展之前,项目经理同产品部门达成一致,明确产品的形态,功能等,项目经理输出backlog,针对本次迭代,列出需求列表,并进行优先级排列。

    2.

    (1)backlog输出后组织开发人员进行本次迭代会议,会议上向所有开发人员通报本次迭代的任务,时间点。

    (2)根据本轮迭代的需求按照story的优先级,组织大家进行任务的认领。此时有两种方式,一种是项目经理根据每个开发人员的特点指定任务,另一种是让大家自己根据兴趣认领。

    (3)第三步与第二步其实是并列的,安排story的时候需要评估工作量。工作量的评估也有两种方式,一种是大家举手表决,比如对于story A,三个人给出的工作量是4天,另外两人给出的5天和3天,这个时候就需要最低和最高的给出具体的原因分析,最后取合理值。另外一种是个人认领了相应的story,这时候可以给出工作量,或者在任务分配后,预留一段时间,会后大家反馈给项目经理。

          注意:工作量的评估不单单包括开发的过程,还包括前期的分析设计,自测以及测试部的签收等,要预留出时间,以免工作量评估与时间时间相差悬殊。

    (4)迭代会议完成后,项目经理在确定完工作量后,将backlog归档,后期按照这个结果进行每天的项目进度跟踪。

    (5)正式迭代开始前,所有的story都需要上状态墙,状态墙分为以下几个部分:初始化、分析、设计、编码、自测、BA验收、测试,最初story都走到初始化阶段。

    (6)迭代开始,每天早上进行站立会议,时间尽量缩短,每人不超过2分钟,先描述自己昨天干了什么工作,今天准备干什么,同时将相应的story移到对应的状态。

    (7)本轮迭代结束,项目经理召开迭代总结会议,针对本次迭代的情况,进行总结。主要包括以下几个方面:迭代是否符合预期,有没有延期等。然后组织大家针对本次迭代过程有哪些好的方面和不好的方面,每人分别写几条。项目经理进行归类,挑选出公认的观点,进行总结,同时督促大家在下一轮迭代过程中发扬上次的优点,避免上次的缺点。

            以上就是敏捷开发的全部过程。在实践的过程中,要根据项目本身的情况,如果团队人员较多,可以划分出来,比如安卓和iOS,还可以按业务再细分,每次早会时间控制在15分钟以内,提高效率。此外,backlog确定后,迭代过程中不要插入其他需求,破坏敏捷的完整性,新需求放到下次迭代。

            欢迎大家添加我的微信,有任何问题都可以一起讨论,不限于安卓,iOS,后台,项目管理,创业等。

     

    展开全文
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...

        本文阐述敏捷开发的相关要点,做到理解切忌照搬硬套,特别是如果针对面试,对于场景类的描述,一定要变通!

    敏捷开发的一些问题
    说一下你对敏捷开发的理解,为什么要使用敏捷开发?
    》瀑布模型的典型问题就是周期长,发布烦,变更难。
    》敏捷开发就是快速迭代,持续集成,拥抱变化。
        所谓“敏捷”,顾名思义,可以通俗的理解为“短平快”,抽象点的可以说是“一种需求进化”。
    采用快速迭代、循序渐进的方法进行软件开发,通过持续交付的方式不断的交付一个一个子系统,每个交付的子系统都经过测试,具备可集成可运行的特征(这也决定了大的项目在一开始就要被合理的规划和切分为多个子项目)。换个说法就是把一个大项目拆分为多个相互联系,但也可以独立运行的小项目,并分别完成。
        a) 因为敏捷开发的特征,将项目的大目标切分为N个小目标,使得每个目标都简单直观可达性更强。不管是客户、项目经理还是开发者本身,能快速的看到“成果”都是一种好事。化整为零的方式是一种更好的方式,就好像搭积木,将复杂事情简单化的,问题这个攻克,项目逐块交付。
        b) 对于客户而言,也有这样一个场景:我做过整体交付的项目,也带过持续交付的项目。同样跨度都是八九个月(你要能对应到你简历上的具体项目,别一问就穿了)。其中一个项目就是,我们分了4次迭代交付,前面几个月交付了一个版本。客户就推向市场下发给普通用户使用了,然后后面每隔一个月上了一块功能。这样对客户来说可以更快的抢占市场(我理解市场的时间价值成本是非常昂贵的)。不断的更新新的模块,从用户角度也能感知产品的升级带来的效果(这就是为什么我们有的APP产品要每隔1年左右做一个UI改版一样,明明业务没有什么改变,单也要换个皮,其目的就是为了用户,话说不在乎用户感受的项目经理和产品都是不合格)。
        c) 还有就是甲方一般都特别担心的质量问题:谁付钱谁忧虑这本就人之常情,敏捷开发逐步交付的成果“相对较小”,对于质量更容易量化,因为持续交付,问题可以提前发现提前解决。不合理的问题可以“提前转舵”,避免后续持续产生类似的问题。
        d) 因为敏捷开发的特性,使得团队互动性增强。因为互动性的增强,使得每个人都能相对收益。
        e) 劣势:上面说了敏捷注重人员的沟通,若项目人员流动大太,会给维护带来不少难度,特别项目存在新手比较多时,老员工比较累。需要项目中存在经验较强的人,要不在大项目中容易遇到瓶颈问题,对项目的把控者有更高的要求,或者在必要的时候公司有相对专业的人或团队给予指导和支持。
    总结: 敏捷开发是是一个非常有价值的方式,特别适用于持续演进的项目(比如互联网产品或长期执行下去的项目)。对于短小交付就彻底结束的项目则不太适合。对产品对成本对成员有价值的东西,没有理由不用。
        严格来说敏捷开发由迭代+增量组成。持续交付的敏捷才是更有价值的,也就是上面说的不止迭代了,还可以不断的增量上新(用户可感知)。
    由于敏捷开发可以不断试错,迎合市场的可以加强投入,反之可以淘汰。而不是等整个大而全的项目完整完成统一上线才发现就有些不合适了。

    上面是叙述,下面的内容来自互联网,供参考(要理解记忆和挑几点说就行了):

    一、敏捷开发技术的几个特点和优势:
    1.个体和交互胜过过程和工具
    2.可以工作的软件胜过面面俱到的文档
    3.客户合作胜过合同谈判
    4.响应变化胜过遵循计划
    二、敏捷开发技术的原则:
    1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    2.即使到了开发的后期,也欢迎改变需求。
    3.经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好。
    4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    5.围绕被激励起来的个人来构建项目。
    6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
    7.工作的软件是首要的进度度量标准。
    8.敏捷过程提倡可持续的开发速度。
    9.不断地关注优秀的技能和好的设计会增强敏捷能力。
    10.简单使未完成的工作最大化。
    11.最好的构架、需求和设计出自于自组织的团队。
    12.每隔一定时间,团队会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整。
    三、敏捷开发技术的适用范围
    1.项目团队的人数不能太多
    2.项目经常发生变更
    3.高风险的项目实施
    4.开发人员可以参与决策
    四、其他条件
    1.团队要小,人数超过一定规模就要分拆
    2.团队成员之间要紧密协作,客户也要自始至终深度配合
    3.领导们得支持。敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性
    4.写代码时要有一定比例的自动化测试代码,要花时间搭建好源码管理和持续集成环境。

    你哪个项目中使用了敏捷开发?如何实施敏捷开发?产生了哪些实际效果?
        上面敏捷开发的理解和方式,其实对面试官考察表达能力和理解能力的。现在这个问题更重要的是“如何做的”,能真正知道怎么做的,才是相对靠谱的,因为执行力很重要。
        关于敏捷开发方面如何管理,如何计划,如何把控更偏重于管理,根据自己经验,使用“举例场景”的方式叙述,下面说一下微服务和持续集成的一些要点。
    举例说明之前做的某项目或某项目和某项目是自己实践过的。
        当今主流方式微服务、CICD、容器化、自动化,你可以说你当时使用了微服务、CICD、容器(也不一定说全,你不是万能的,有的工作是有单独的团队做的,但是你要强调你在不同团队协作中的作用,这也是你胜任项目经理的职责)持续部署和自动化测试一般都有独立的运维和测试团队来完成,但是你作为项目经理,你也不能只会协调(开发、测试、运维三板斧的第一板斧是必须要擅长的)
        微服务按业务拆分,做到业务层面的高内聚低耦合。有利于扩展也是微服务的一大特性。作为项目经理,前期你抓设计,做好计划的基础性,自己主要负责或者带领核心开发人员构建良好的基础框架并编写封装公共代码(你要叙述你参与了重点技术工作)。持续交付和微服务开发,基础很重要,这是“速度”的基础(比如高铁的铁轨要求就很高)。必要基础平台和基础框架是堆积业务的根本(你可以说你最近几年做的项目和产品自己本身也积累了相关经验)。
        实施敏捷开发,前期要做好很好的设计功底,该拆的拆该细化的细化。你当时推动的时候,不能一蹴而就,要使用新的业务模块来演进(这也是引入任何新的东西的一种常用方式),也叫“试水”。将风险较低的业务走这种路线,打造一个完整的体系后,接下来就是其他业务逐步迁移的事了。如果老业务不需要迁移升级,未来的新需求按新的方式进行即可。
        实施过程中,需要公司领导和重要技术岗位成员的支持,比如你当时项目中因为推动的时候也有一些成员排斥、遇到了一些阻力(革命哪有不流血的,适应了就好)。跟相关人说明这样做的原因,甚至可以说这是公司领导层对未来趋势的要求(有时候把领导搬出来也是做事的一种方法,可以适当的采用,做人做事要灵活嘛)。然后从自己负责的范围内(毕竟自己对自己这块还是有话语权的)推进和落实,再横向推动到其他团队甚至整个公司(整个过程是需要很长时间的,不要张口就说你一个月就推完了(如果你直接上到一个没有包袱的新项目中那可能很快),正常来说整个公司都演进下来步入整个轨道,至少半年以上,1年左右很正常,因为公司本身业务是要持续前进的,不是停下业务的脚步只干技改)。
        产生的效果:很明显,老板经常能看到产品在变动,不断有功能上线也获得了用户的反馈(当时有的用户甚至说:呀,最近XXX客户端的程序猿是不是开启机器人模式了,老发版发功能,面试是一个综合的过程,不只是死气沉沉的回答问题,你既然是项目经理活跃气氛也是这个岗位的职责)。还有就是我们为快速迭代拆了微服务,当时就有某个模块因为开发代码写的不够好性能压力上来了,我们单独给这个服务加了个节点部署,开发都没参与,运维搞一下扩展个节点即可(然后开发这边优化处理后又升级的)。如果是中心化系统,要整个系统部署一套,影响面就不好说了。
        刚刚也提到了CICD,你当时进公司的时候公司是什么现状(比如大家都是手工做事,经常出一些小问题,回退版本什么的都麻烦,发布包管理不够好,经常扯皮等等)你的CI是基于Jenkins的(按你对行业的持续关注度一般来说Jenkins可以满足大部分公司使用,如果公司的基础平台和架构团队发展到一定程度,变会衍生开发自有平台):你们当时基于git管理代码,因为git更适用于CI,分支和版本很强大。开发者提交代码后,Jenkins可以感知代码变动,会自动对代码进行编译,如果编译失败发送邮件通知开发者。同时会自动触发sonarqube进行代码扫描,开发者可以到sonar平台查看代码的质量问题,对存在的隐患bug或不规范写法进行纠正(你可以说很多时候机器比人靠谱所以代码扫描很有必要,重要的业务逻辑需要人工参与代码review)。你写了Jenkinsfile文件,使用pipeline脚本(你说到这块对方一般就知道你真实使用了)做了配置,针对develop、release、master(gitflow的分支模型你要了解一下,人家可能会问你分支模型)分支会自动将编译后的包打成docker镜像并自动发布到docker仓库。你要求重要的业务必须要写junit用例(可以说下因为写junit用例会增加开发量,所以你根据项目和公司的质量情况做的要求是针对核心和重要业务必须写没有强制全部写因为需要代价啊也就是要花钱啊,代价和成本是项目经理要考虑的职责),这是CI的过程。
        CD的过程,也是基于Jenkins触发服务器脚本来实现自动发布(服务器脚本前期采用docker-compose简单化编排),后期公司让运维慢慢引入了K8S(你如果熟你可以详细说,如果这块不熟悉,你就说这块交给了专业的运维,这块更重运维)。K8S给Jenkins提供一些脚本和接口,CD这块便OK了(在前期直接Jenkins操作服务器脚本完成自动部署)。

    使用微服务进行敏捷开发要解决哪些问题?
        服务被颗粒化之后,就更适合容器化了,现在docker+springboot微服务组合比较常见。
    服务多了,就要管理,管理代价就会提示,加上容器化之后容器可能随时升级被整体删除替代。加上springboot的打包方式(jar)和docker镜像的方式,使得配置可变性变的困难,文件存储、日志、配置、调度,这些都要提取进行统一管理,服务的注册发现可以使用Spring的Eureka,服务调用使用Feign,你熟悉dubbo的话也可以说。如果使用容器,有专业的运维可以上K8S一套进行容器编排更好。
        比如日志使用ELK,可以在docker内启动filebeat被动收集日志,也可以在项目中直接将日志写入Logstash、kafka、ElasticSeach都有方案(高可用的架构会带来复杂度,所以要根据项目实际业务情况选型决定,任何脱离业务的技术架构都是耍流氓)。
    配置中心你使用过Spring Cloud Config 、Nacos、Disconf,现在使用Apollo(或其他,你熟悉哪个就说哪个,不过Apollo现在挺主流的),这2个东西你要简单了解下,更多的你要告诉对方你为什么用这个。或者为什么从A换成了B。
        调度中心,用xxljob就够用(如果你自研过也可以讲讲,根据自身情况介绍),也OK。
        公司有独立的文件系统,你知道的提一下就行,你也可以说你直接用的阿里云OSS(或其他你熟悉的NAS、fastdfs、ceph等等)。
        服务化之后,服务变多了。全链路跟踪也变的更为必要,这个你之前的方案是SpringCloudSleuth+Zipkin,你如果熟悉Jaeger也可以说。
        监控方面,SpringCloud的Hystrix Dashboard+ Turbine。
    其他方面的,根据自己情况发挥,这些应该说了不少了。只要你理解了并描述清楚,基本也差不多了。
        不是每个人都可以全盘非常熟悉所有,对于会用和没有深入研究的。你可以根据自己的岗位来折中的回复对方。比如你是项目经理,你重点在项目成员、进度和质量把控,但是你持续关注技术,也会参与重点开发,平时重点解决团队内大家都不熟悉的技术(让开发人员更专注业务开发)。如果某块有很熟悉的团队成员,可以更好的利用团队成员的能力,把人用好对项目经理来说也很重要。
    相关的问题可能性太多了,平时还是要多看资料,灵活的协调人和回答问题本身也是一种能力,所以面试上不仅仅只考验纯技术,其实是对一个人的综合判断。

    有一句话是这么说的:敏捷是瓷器活,你得有金刚钻。字里行间都表达了对人的能力的要求。

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

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

    敏捷开发原则

    敏捷建模(AM)定义了一系列的核心原则和辅助原则,它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来,在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见!基本上,本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作;这样,对于这些借鉴于XP的原则,我们可以从另一个角度来看待。

    核心原则

    ◆主张简单

    当从事开发工作时,你应当主张最简单的解决方案就是最好的解决方案。不要过分构建(overbuild)你的软件。用AM的说法就是,如果你现在并不需要这项额外功能,那就不要在模型中增加它。要有这样的勇气:你现在不必要对这个系统进行过分的建模(over-model),只要基于现有的需求进行建模,日后需求有变更时,再来重构这个系统。尽可能的保持模型的简单。

    ◆拥抱变化

    需求时刻在变,人们对于需求的理解也时刻在变。项目进行中,Project stakeholder可能变化,会有新人加入,也会有旧人离开。Project stakeholder的观点也可能变化,你努力的目标和成功标准也有可能发生变化。这就意味着随着项目的进行,项目环境也在不停的变化,因此你的开发方法必须要能够反映这种现实。

    ◆你的第二个目标是可持续性

    即便你的团队已经把一个能够运转的系统交付给用户,你的项目也还可能是失败的--实现项目投资者的需求,其中就包括你的系统应该要有足够的鲁棒性(robust ),能够适应日后的扩展。就像Alistair Cockburn常说的,当你在进行软件开发的竞赛时,你的第二个目标就是准备下一场比赛。可持续性可能指的是系统的下一个主要发布版,或是你正在构建的系统的运转和支持。要做到这一点,你不仅仅要构建高质量的软件,还要创建足够的文档和支持材料,保证下一场比赛能有效的进行。你要考虑很多的因素,包括你现有的团队是不是还能够参加下一场的比赛,下一场比赛的环境,下一场比赛对你的组织的重要程度。简单的说,你在开发的时候,你要能想象到未来。

    ◆递增的变化

    和建模相关的一个重要概念是你不用在一开始就准备好一切。实际上,你就算想这么做也不太可能。而且,你不用在模型中包容所有的细节,你只要足够的细节就够了。没有必要试图在一开始就建立一个囊括一切的模型,你只要开发一个小的模型,或是概要模型,打下一个基础,然后慢慢的改进模型,或是在不在需要的时候丢弃这个模型。这就是递增的思想。

    ◆令投资最大化

    你的项目投资者为了开发出满足自己需要的软件,需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资,也可以要求你的团队不浪费资源。并且,他们还有最后的发言权,决定要投入多少的资源。如果是这些资源是你自己的,你希望你的资源被误用吗。

    ◆有目的的建模

    对于自己的产出,例如模型、源代码、文档,很多开发人员不是担心它们是否够详细,就是担心它们是否太过详细,或担心它们是否足够正确。你不应该毫无意义的建模,应该先问问,为什么要建立这个产出,为谁建立它。和建模有关,也许你应该更多的了解软件的某个方面,也许为了保证项目的顺利进行,你需要和高级经理交流你的方法,也许你需要创建描述系统的文档,使其他人能够操作、维护、改进系统。如果你连为什么建模,为谁建模都不清楚,你又何必继续烦恼下去呢?首先,你要确定建模的目的以及模型的受众,在此基础上,再保证模型足够正确和足够详细。一旦一个模型实现了目标,你就可以结束工作,把精力转移到其它的工作上去,例如编写代码以检验模型的运作。该项原则也可适用于改变现有模型:如果你要做一些改变,也许是一个熟知的模式,你应该有做出变化的正确理由(可能是为了支持一项新的需求,或是为了重构以保证简洁)。关于该项原则的一个重要暗示是你应该要了解你的受众,即便受众是你自己也一样。例如,如果你是为维护人员建立模型,他们到底需要些什么?是厚达500页的详细文档才够呢,还是10页的工作总览就够了?你不清楚?去和他们谈谈,找出你想要的。

    ◆多种模型

    开发软件需要使用多种模型,因为每种模型只能描述软件的单个方面,“要开发现今的商业应用,我们该需要什么样的模型?”考虑到现今的软件的复杂性,你的建模工具箱应该要包容大量有用的技术(关于产出的清单,可以参阅AM的建模工件)。有一点很重要,你没有必要为一个系统开发所有的模型,而应该针对系统的具体情况,挑选一部分的模型。不同的系统使用不同部分的模型。比如,和家里的修理工作一样,每种工作不是要求你用遍工具箱里的每一个工具,而是一次使用某一件工具。又比如,你可能会比较喜欢某些工具,同样,你可会偏爱某一种模型。有多少的建模工件可供使用呢,如果你想要了解这方面的更多细节,我在Be Realistic About the UML中列出了UML的相关部分,如果你希望做进一步的了解,可以参阅白皮书The Object Primer -- An Introduction to Techniques for Agile Modeling。

    ◆高质量的工作

    没有人喜欢烂糟糟的工作。做这项工作的人不喜欢,是因为没有成就感;日后负责重构这项工作(因为某些原因)的人不喜欢,是因为它难以理解,难以更新;最终用户不喜欢,是因为它太脆弱,容易出错,也不符合他们的期望。

    ◆快速反馈

    从开始采取行动,到获得行动的反馈,二者之间的时间至关紧要。和其他人一共开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候,例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作,去了解他们的的需求,去分析这些需求,或是去开发满足他们需求的用户界面,这样,你就提供了快速反馈的机会。

    ◆软件是你的主要目标

    软件开发的主要目标是以有效的方式,制造出满足投资者需要的软件,而不是制造无关的文档,无关的用于管理的工件,甚至无关的模型。任何一项活动(activity ),如果不符合这项原则,不能有助于目标实现的,都应该受到审核,甚至取消。

    ◆轻装前进

    你建立一个工件,然后决定要保留它,随着时间的流逝,这些工件都需要维护。如果你决定保留7个模型,不论何时,一旦有变化发生(新需求的提出,原需求的更新,团队接受了一种新方法,采纳了一项新技术...),你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型,很明显,你实现同样的改变要花费的功夫就少多了,你的灵活性就增强了,因为你是在轻装前进。类似的,你的模型越复杂,越详细,发生的改变极可能就越难实现(每个模型都更“沉重”了些,因此维护的负担也就大了)。每次你要决定保留一个模型时,你就要权衡模型载有的信息对团队有多大的好处(所以才需要加强团队之间,团队和项目投资者之间的沟通)。千万不要小看权衡的严重性。一个人要想过沙漠,他一定会携带地图,帽子,质地优良的鞋子,水壶。如果他带了几百加仑的水,能够想象的到的所有求生工具,一大堆有关沙漠的书籍,他还能过得去沙漠吗?同样的道理,一个开发团队决定要开发并维护一份详细的需求文档,一组详细的分析模型,再加上一组详细的架构模型,以及一组详细的设计模型,那他们很快就会发现,他们大部分的时间不是花在写源代码上,而是花在了更新文档上。

    宣言原则

    最重要的是通过尽早和不断交付有价值的软件满足客户需要。

    我们欢迎需求的变化,即使在开发后期。敏捷过程能够驾驭变化,保持客户的竞争优势。

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

    业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

    围绕斗志高昂的人进行软件开发,给开发者提供适宜的环境,满足他们的需要,并相信他们能够完成任务。

    在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

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

    敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

    对卓越技术与良好设计的不断追求将有助于提高敏捷性。

    简单——尽可能减少工作量的艺术至关重要。

    最好的架构、需求和设计都源自自我组织的团队。

    每隔一定时间,团队都要总结如何更有效率,然后相应地调整自己的行为。

    敏捷成功之道

    随机应变

    要达到敏捷的成功—交付支撑业务的最佳软件—软件专家也可以引用这些规则。

    自主权

    专注于工作,交付正确的软件,而不是被他人的愤怒情绪所影响。

    分享经验

    构建完美软件开发流程,并没有统一的模式。但是在这个领域,敏捷技术,加上持续的应用和改进,都能够达到敏捷的成功。

    敏捷开发相关工具

    Visual Studio Team Foundation Server

    TFS,即团队基础服务器是微软应用程序生命周期管理服务器,用于帮助团队在Visual Studio的协作开发。最近,它进有了升级包括工作项目执行改进、富文本编辑器的改进,以及富文本编辑器中改善的超链接体验。 TFS中的Kanban面板也做了改善,提升了可以录入和跟踪的项目数量,该服务器现在有一个“利益相关者”许可,来规范服务器的访问权限。

    Atlassian Jira

    Atlassian的是一个很流行的工具,主要用于跟踪产品开发、帮助团队整理问题、安排工具,以及记录团队行为。它Jira Agile插件使开发人员更容易部署关键敏捷策略,这包括用户故事开发、冲刺模块构建,以及可视化的团队活动。

    Axosoft

    Axosoft以前被称为Axosoft OnTime Scrum,这一软件套件有四个功能模块:Scrum、Bug追踪器、帮助台和Wiki。它是基于HTML5构建的,帮助开发团队管理待办事项列表、发布和冲刺,带有燃尽图功能,有一个 管理仪表板用于跟踪编码和修改BUG的时间。

    LeanKit

    使用 LeanKit的团队可以看到工作负载的分布并导出历史数据。最近 LeanKit 进行了一次升级,包含单点登录功能 和附加报告功能,从而提供更细粒度的数据详细信息。

    Planbox

    Planbox 敏捷管理工具通过燃尽图跟踪进程,集成客户反馈,它的目标人群很广泛。最近它对应用的前端和后端都做的升级,添加了更强大的报告功能和新仪表盘,来提升项目速度。时间跟踪特性和工具允许用户得到所有他们在Planbox产生的数据。

    敏捷开发实践

    敏捷建模(AM)在AM原则的基础上定义了一组核心实践(practice)和补充实践,其中的某些实践已经是极限编程(XP)中采用了的,并在 Extreme Programming Explained一书中有详细的论述,和AM的原则一样,我们在描述这组实践时,将会注重于建模的过程,这样你可以从另外一个角度来观察这些已或XP采用的素材。

    核心实践

    ◆Stakeholder的积极参与 我们对XP的现场客户(On-Site Customer)的概念做了一个扩充:开发人员需要和用户保持现场的接触;现场的用户要有足够的权限和能力,提供建构中的系统相关的信息;及时、中肯的做出和需求相关的决策;并决定它们的优先级。AM把XP的“现场客户”实践扩展为“使project stakeholder积极参与项目”,这个project stakeholder的概念包括了直接用户、他们的经理、高级经理、操作人员、支持人员。这种参与包括:高级经理及时的资源安排决策,高级经理的对项目的公开和私下的支持,需求开发阶段操作人员和支持人员的积极参与,以及他们在各自领域的相关模型。

    ◆正确使用artifact 每个artifact都有它们各自的适用之处。例如,一个UML的活动图(activity diagram)适合用于描述一个业务流程,反之,你数据库的静态结构,最好能够使用物理数据(physical data)或数据模型(persistence model)来表示。在很多时候,一张图表比源代码更能发挥作用,一图胜千言,同样,一个模型也比1K的源代码有用的多,前提是使用得当(这里借用了 Karl Wieger的Software Requirements中的词汇)。因为你在研究设计方案时,你可和同伴们和在白板上画一些图表来讨论,也可以自己坐下来开发一些代码样例,而前一种方法要有效的多。这意味着什么?你需要了解每一种artifact的长处和短处,当你有众多的模型可供选择的时候,要做到这一点可没有那么容易。

    ◆集体所有制 只要有需要,所有人都可以使用、修改项目中的任何模型、任何artifact。

    ◆测试性思维 当你在建立模型的时候,你就要不断的问自己,“我该如何测试它?”如果你没办法测试正在开发的软件,你根本就不应该开发它。在现代的各种软件过程中,测试和质保(quality assurance)活动都贯穿于整个项目生命周期,一些过程更是提出了“在编写软件之前先编写测试”的概念(这是XP的一项实践:“测试优先”)。

    ◆并行创建模型 由于每种模型都有其长处和短处,没有一个模型能够完全满足建模的需要。例如你在收集需求时,你需要开发一些基本用例或用户素材,一个基本用户界面原型,和一些业务规则。再结合实践切换到另外的Artifact,,敏捷建模者会发现在任何时候,同时进行多个模型的开发工作,要比单纯集中于一个模型要有效率的多。

    ◆创建简单的内容 你应该尽可能的使你的模型(需求、分析、架构、设计)保持简单,但前提是能够满足你的project stakeholder的需要。这就意味着,除非有充分的理由,你不应该随便在模型上画蛇添足--如果你手头上没有系统认证的功能,你就不应该给你的模型增加这么一个功能。要有这样的勇气,一旦被要求添加这项功能,自己就能够马上做到。这和XP的实践“简单设计”的思想是一样的。

    ◆简单地建模 当你考虑所有你能够使用的图表(UML图、用户界面图、数据模型等)时,你很快会发现,大部分时候你只需要这些图表符号的一部分。一个简单的模型能够展示你想要了解的主要功能,例如,一个类图,只要能够显示类的主要责任和类之间的关系就已经足够了。不错,编码的标准告诉你需要在模型中加入框架代码,比如所有的get和set操作,这没有错,但是这能提供多少价值呢?恐怕很少。

    ◆公开展示模型 你应当公开的展示你的模型,模型的载体被称为“建模之墙”(modeling wall)或“奇迹之墙(wall of wonder)”。这种做法可以在你的团队之间、你和你的project stakeholder之间营造出开放诚实的沟通氛围,因为当前所有的模型对他们都是举手可得的,你没有向他们隐藏什么。你把你的模型贴到建模之墙上,所有的开发人员和project stakeholder都可以看建模之墙上的模型,建模之墙可能是客观存在的,也许是一块为你的架构图指定的白板,或是物理数据模型的一份打印输出,建模之墙也可能是虚拟的,例如一个存放扫描好的图片的internet网页。如果你想要多了解一些相关的资料,你可以看看Ellen Gottesdiener的Specifying Requirements With a Wall of Wonder。

    ◆切换到另外的Artifact 当你在开发一个artifact(例如用例、CRC卡片、顺序图、甚至源码),你会发现你卡壳了,这时候你应当考虑暂时切换到另一个artifact。每一个artifact都有自己的长处和短处,每一个artifact都适合某一类型的工作。无论何时你发现你在某个artifact上卡壳了,没办法再继续了,这就表示你应该切换到另一个artifact上去。举个例子,如果你正在制作基本用例,但是在描述业务规则时遇到了困难,你就该试着把你的注意力转移到别的artifact上去,可能是基本用户界面原型、CRC模型,可能是业务规则、系统用例、或变化案例。切换到另一个artifact上去之后,你可能就立刻不再卡壳了,因为你能够在另一个artifact上继续工作。而且,通过改变你的视角,你往往会发现原先使你卡壳的原因。

    ◆小增量建模 采用增量开发的方式,你可以把大的工作量分成能够发布的小块,每次的增量控制在几个星期或一两个月的时间内,促使你更快的把软件交付给你的用户,增加了你的敏捷性。

    ◆和他人一起建模 当你有目的建模时你会发现,你建模可能是为了了解某事,可能是为了同他人交流你的想法,或是为了在你的项目中建立起共同的愿景。这是一个团体活动,一个需要大家有效的共同工作才能完成的活动。你发现你的开发团队必须共同协作,才能建立一组核心模型,这对你的项目是至关重要的。例如,为了建立系统的映像和架构,你需要和同组成员一起建立所有人都赞同的解决方案,同时还要尽可能的保持它的简单性。大多数时候,最好的方法是和另一些人讨论这个问题。

    ◆用代码验证 模型是一种抽象,一种能够正确反映你正在构建的系统的某个方面的抽象。但它是否能运行呢?要知道结果,你就应该用代码来验证你的模型。你已经用一些HTML页面建立了接受付款地址信息的草图了吗?编码实现它,给你的用户展示最终的用户界面,并获取反馈。你已经做好了表示一个复杂业务规则逻辑的UML顺序图了吗?写出测试代码,业务代码,运行测试以保证你做的是对的。永远也别忘了用迭代的方法开发软件(这是大多数项目的标准做法),也别忘了建模只是众多任务中的一个。做一会儿建模、做一会儿编码、做一会儿测试(在其它的活动之中进行)。

    ◆使用最简单的工具 大多数的模型都可以画在白板上,纸上,甚至纸巾的背面。如果你想要保存这些图标,你可以用数码相机把它们拍下来,或只是简单的把他们转录到纸上。这样做是因为大多数的图表都是可以扔掉的,它们只有在你画出模型并思考一个问题的时候才有价值,一旦这个问题被解决了它们就不再有意义了。这样,白板和标签往往成为你建模工具的最佳选择:使用画图工具来创建图表,给你重要的project stakeholder看。只有建模工具能够给我们的编程工作提供价值(例如代码自动生成)时才使用建模工具。你可以这样想:如果你正在创建简单的模型,这些模型都是可以抛弃的。你建模的目的就是为了理解,一旦你理解了问题,模型就没有存在的必要了,因此模型都是可以丢弃的,这样,你根本就不必要使用一个复杂的建模工具。

    补充实践

    ◆使用建模标准 这项实践是从XP的编码标准改名而来,基本的概念是在一个软件项目中开发人员应该同意并遵守一套共同的建模标准。遵守共同的编码惯例能够产生价值:遵守你选择的编码指南能够写出干净的代码,易于理解,这要比不这么做产生出来的代码好得多。同样,遵守共同的建模标准也有类似的价值。可供选择的建模标准有很多,包括对象管理组织(OMG)制定的统一建模语言ML),它给通用的面向对象模型定义了符号和语义。UML开了一个好头,但并不充分-就像你在Be Realistic About The UML中看到的,UML并没有囊括所有可能的的建模artifact。而且,在关于建立清楚可看的图表方面,它没有提供任何建模风格指南。那么,风格指南和标准之间的差别在何处呢。对源代码来说,一项标准可能是规定属性名必须以attributeName的格式,而风格指南可能是说在一个单元中的一段控制结构(一个if语句,一段循环)的代码缩进。对模型来说,一项标准可能是使用一个长方形对类建模,一项风格指南可能是图中子类需要放在父类的下方。

    ◆逐渐应用模式 高效的建模者会学习通用的架构模式、设计模式和分析模式,并适当的把它们应用在模型之中。然而,就像Martin Fowler在Is Design Dead中指出的那样,开发人员应当轻松的使用模式,逐渐的应用模式。这反映了简单的价值观。换言之,如果你猜测一个模式可能适用,你应当以这样的方式建模:先实现目前你需要的最小的范围,但你要为日后的重构留下伏笔。这样,你就以一种可能的最简单的方式实现了一个羽翼丰满的模式了。就是说,不要超出你的模型。举一个例子,在你的设计中,你发现有个地方适合使用GoF的Strategy模式,但这时候你只有两个算法要实现。最简单的方法莫过于把算法封装为单独的类,并建立操作,能够选择相应的算法,以及为算法传递相关的输入。这是Strategy模式的部分实现,但你埋下了伏笔,日后如有更多的算法要实现,你就可以重构你的设计。并没有必要因为Strategy模式需要,就建立所有的框架。这种方法使你能够轻松的使用模式。

    ◆丢弃临时模型 你创建的大部分的模型都是临时使用的模型--设计草图,低精度原型,索引卡片,可能架构/设计方案等等--在它们完成了它们的目的之后就再不能提供更多的价值了。模型很快就变得无法和代码同步,这是正常的。你需要做出决定:如果“同步更新模型”的做法能够给你的项目增添价值的话,那就同步更新模型;或者,如果更新它们的投入将抵消它们能够提供的所有价值(即负收益),那就丢弃它们。

    ◆合同模型要正式 在你的系统需要的信息资源为外部组织所控制的时候,例如数据库,旧有系统和信息服务,你就需要合同模型。一个合同模型需要双方都能同意,根据时间,根据需要相互改变。合同模型的例子有API的细节文档,存储形式描述,XML DTD或是描述共享数据库的物理数据模型。作为法律合同,合同模型通常都需要你投入重要资源来开发和维护,以确保它的正确、详细。你的目标是尽量使你系统的合同模型最少,这和XP的原则traveling light是一致的。注意你几乎总是需要电子工具来建立合同模型,因为这个模型是随时需要维护的。

    ◆为交流建模 建模的次要原因是为了和团队之外的人交流或建立合同模型。因为有些模型是给团队之外的客户的,你需要投入时间,使用诸如文字处理器,画图工具包,甚至是那些“被广告吹得天花乱坠”的CASE工具来美化模型。

    ◆为理解建模 建模的最重要的应用就是探索问题空间,以识别和分析系统的需求,或是比较和对照可能的设计选择方法,以识别可能满足需求的、最简单的解决方案。根据这项实践,你通产需要针对软件的某个方面建立小的、简单的图表,例如类的生命周期图,或屏幕顺序,这些图表通常在你完成目的(理解)之后就被丢弃。

    ◆重用现有的资源 这是敏捷建模者能够利用的信息财富。例如,也许一些分析和设计模式适合应用到系统上去,也许你能够从现有的模型中获利,例如企业需求模型,业务过程模型,物理数据模型,甚至是描述你用户团体中的系统如何部署的模型。但是,尽管你常常搜索一些比较正确的模型,可事实是,在大多数组织中,这些模型要么就不存在,要么就已经过期了。

    ◆非到万不得已不更新 你应当在你确实需要时才更新模型,就是说,当不更新模型造成的代价超出了更新模型所付出的代价的时候。使用这种方法,你会发现你更新模型的数量比以前少多了,因为事实就是,并不是那么完美的模型才能提供价值的。我家乡的街道图已经使用了5年了,5年我自己街道并没有改变位置,这张地图对我来说还是有用的。不错,我可以买一张新地图,地图是每年出一次的,但为什么要这么麻烦呢?缺少一些街道并没有让我痛苦到不得不投资买一份新地图。简单的说,当地图还管用的时候,每年花钱买新地图是没有任何意义的。为了保持模型、文档和源代码之间的同步,已经浪费了太多太多的时间和金钱了,而同步是不太可能做到的。时间和金钱投资到新的软件上不是更好吗?

    确实不错的主意

    以下的实践虽然没有包括在AM中,但是可以做为AM的一份补充:

    ◆重构 这是一项编码实践。重构,就是通过小的变化,使你的代码支持新的功能,或使你的设计尽可能的简单。从AM的观点来看,这项实践可以保证你在编码时,你的设计干净、清楚。重构是XP的一个重要部分。

    ◆测试优先设计 这是一项开发实践。在你开始编写你的业务代码之前,你要先考虑、编写你的测试案例。从AM的观点来看,这项实践强制要求你在写代码之前先通盘考虑你的设计,所以你不再需要细节设 计建模了。测试优先设计是XP的一个重要部分。

    敏捷开发名词详解

    AM是一种态度,而不是一个说明性的过程。AM是敏捷建模者们坚持的价值观、敏捷建模者们相信的原则、敏捷建模者们应用的实践组成的集合。AM描述了一种建模的风格。当它应用于敏捷的环境中时,能够提高开发的质量和速度,同时能够避免过度简化和不切实际的期望。AM可不是开发的“食谱”,如果你寻觅的是一些细节的指导,如建立UML顺序图或是画出用户界面流图,你可以看看在建模Artifacts中列出的许多建模书籍,我特别推荐我的书The Object Primer 2/e(尽管这有失公允)。

    AM是对已有方法的补充,而不是一个完整的方法论。AM的主要焦点是在建模上,其次是文档。也就是说,AM技术在你的团队采用敏捷方法(例如eXtreme Programming,Dynamic Systems Development Method (DSDM),Crystal Clear)的基础上能够提高建模的效果。AM同样也可以用于那些传统过程(例如Unified Process),尽管这种过程较低的敏捷性会使得AM不会那么成功。

    AM是一种有效的共同工作的方法,能够满足Project Stakeholder的需要。敏捷开发者们和Project Stakeholder进行团队协作,他们轮流在系统开发中扮演着直接、主动的角色。在“敏捷”的字典中没有“我”这个单词。

    AM是有效的,而且也已开始有效。当你学习到更多的AM知识时,有件事对你来说可能不好接受,AM近乎无情的注重有效性。AM告诉你:要使你的 Project Stakeholder的投资最大化;当有清晰的目的以及需要了解受众的需要时要建立模型或文档;运用合适的工件来记录手头的情形;不论何时都尽可能创建简单的模型。

    AM不是灵丹妙药。敏捷建模是改进众多专家软件开发成果的有效技术,充其量也就是这样了。它并不是什么了不得的灵丹妙药,能够解决你开发中的所有问题。如果你努力的工作;如果你专注其上;如果打心眼儿里接受它的价值观、它的原则、它的实践;你就可以改进你做为一个开发人员的效果。

    AM是面向一般的开发人员的,但并不是要排斥有能力的人。AM的价值观、原则和实践都简单易懂,其中的很多内容,可能你都已经采用或期待多年了。应用AM技术并不是要你去练水上飘,但你需要有一些基本的软件开发技能。AM最难的就是它逼着你去学习更广泛的建模技术,这是个长期的、持续性的活动。学习建模在一开始可能很难,但你可以试着一次学习一样技术来完成你的学习。

    AM并不是要反对文档。文档的创建和维护都会增大项目涉众的投资。敏捷文档尽可能的简单,尽可能的小,目的只集中在和开发的系统有直接关系的事情上,充分了解受众的需要。

    AM也不是要反对CASE工具。敏捷建模者使用那些能够帮助开发人员提高效果,提升价值的工具。而且,他们还尽力使用那些能够胜任工作的最简单的工具。

    何时是敏捷的?

    要想了解AM,你需要了解模型和敏捷模型之间的区别。模型是一个抽象的概念,它描述了一个的问题的一个或多个方面,或是处理这个问题可能的解决方案。传统意义上,模型被认为是图表加上相应的文档。然而那不够直观的artifact,也可以被视为模型,例如CRC卡片集,单条或多条业务规则的文字描述,或是业务流程的一段结构化英文描述。一个敏捷模型就是一个刚刚足够好的模型。但是你怎么知道什么时候模型才是刚刚足够好呢?当敏捷模型显现出如下的特性时,它就是刚刚足够好的:

    敏捷模型实现了它们的目的。有时你为沟通而建模,或许你需要把你工作的范围告诉高级经理;有时你为理解而建模,或许你需要确定一个设计策略,实现一组Java类。一个敏捷模型是否足够好,要看它是不是满足了创建它时的初衷。

    敏捷模型是可理解的。敏捷模型要能为其预期听众所理解。使用用户能够理解的业务语言来描述需求模型,反之,技术架构模型则需要使用开发人员熟悉的技术术语。你所使用的建模符号会影响易懂性--如果你的用户不了解UML用例图中的符号的含义,那用例图对用户就没有任何价值。这样的话,要么使用另一种方法,要么教授用户学习建模技术。风格问题同样也会影响易懂性,例如避免交叉线。杂乱的图表比清晰的图表难懂。模型的细节程度(见下文),也会影响易懂性,因为相较一个不那么详细的模型来说,一个过于详细的模型要难于理解。简单(见下文)同样是影响易懂性的一个因素。

    敏捷开发

    敏捷模型是足够正确的。模型通常都不需要100%正确,只要足够正确就行了。举个例子,如果一张街道地图漏画了一条街道,或是它标示某条街道是通行的,但你发现它已经关闭维修了,那你会不会扔掉你的地图开始在城里飙车犯罪呢?不太可能。你会考虑更新你的地图,你可能会拿出笔来自己做修改或是去当地的商店买一张最新版的地图(你原来的那张过期了)。也许你还是会接受那张虽不完美但仍可使用的地图,因为它对你来说已经足够好了。你还是可以用这张地图四处转转,因为它还是个正确的模型,标记出了大部分街道的位置。你在发现这张地图不正确的时候,你没有立刻扔掉它,原因是你根本不在乎它是否完美。类似的,当你在需求模型、数据模型中发现错误的时候,你也会选择更新或是接受--虽不完美但已经足够好了。有些项目成员能够容忍这种不正确而有些则不能:这取决于项目的特性,每个团队成员的特性,组织的特性。充分正确性既和模型的听众有关,也和你要处理的问题有关。

    敏捷模型是足够一致的。一个敏捷模型并不需要和自己(或其它有用的artifact)保持完全的一致。如果一个用例在它的一个步骤中显式的调用了另一个用例,那么相应的用例图需要用UML的 <> 版型来标记这两个用例之间的关系。然而,你看了看图表,发现它们并没有这样做,天哪!用例和图之间不一致!危险!太危险了!红色警报!快逃命呀!等一下,你的用例模型是有不一致的地方,但也没到世界末日啊。是的,理想情况下,你的所有artifact最好是能够完全一致,但这通常是不可能的。当我开发一个简单的商用系统时,我通常都可以容忍部分的不一致。但有时我是不能容忍这种不一致的。最有力的佐证就是1999年 NASA发射火星太空探测器时采用了精密的测量系统。要树立一个观点,敏捷模型只要足够一致就行了,你通常不需要使用那么完美的模型。

    关于正确性和一致性,很明显要考虑权衡问题。如果你要维护一个artifact(我们称之为“保管”),随着时间的流逝,你需要投入资源来更新它。否则它很快会就会过期,对你就没用了。例如,我可以容忍一张地图标错了一两条街道,但是我绝对无法容忍一张地图中四分之三的街道都标错了。这就需要权衡了,进行足够的努力,保证artifact足够正确。过多不必要的努力反而会减缓项目的进度,而投入不足就没有办法保证artifact的有效性。

    敏捷模型有足够的细节。一张路线图并不需要标记出每条街道上的每栋房子。那会有太多的细节,使得地图难以使用。然而,在修路的时候,我想施工人员一定会有这条街道的详细地图,包括每幢建筑、下水道、电线盒等足够的细节,这样的地图才是有用的。但是这张地图并不用标记出每个院子和通向它们的路线。因为这样又太繁琐了。足够的细节和听众有关,也和他们使用模型的目的有关--司机需要的是显示道路的地图,施工人员需要的是显示土木工程细节的地图。

    考虑一个架构模型,可能一组画在白板上的图表就足够了--项目的进行中再对它们更新,也许你需要用CASE 工具来生成一些图表,也许这些图表还需要有详细的文档,这依赖于环境。不同的项目有不同的需要。在每一个例子中,实际上你都是在开发、维护一个有足够的细节的架构模型,只是这个“足够的细节”的概念和环境有关。

    敏捷模型能提供正面价值。对项目中的任一artifact,一个基本的要求是它们能够提供正面价值。一个架构模型给你的项目带来的价值是不是能够超过开发它、维护它(可选)的总成本?一个架构模型能够坚定你们团队为之努力的愿景,所以它当然是有价值的。但是,如果它的成本超过了这个价值,那就是说,它无法提供正面价值。投入100,000美元去开发一个详细的、重量级的文档化架构模型,而它的效用,只需一些画在白板上的图表就能够达到,这些图只需要花你 5,000美元,看看,这是多么轻率的做法。

    敏捷模型要尽可能的简单。只要能够达到目的,你应当努力让你的模型尽可能保持简单。模型的详细程度会影响简单性,而所使用的符号范围也会影响简单性。例如,UML的类图就包括了无数的符号,包括对象约束语言 (Object Constraint Language OCL) ,但大多数的图使用符号的一部分就能够完成。所以你常常不需要使用所有的符号,你可以限制自己使用符号的一个子集,当然,这个子集是足够让你完成工作的。

    因此呢,一个敏捷模型的定义就是一个实现它的目的,没有画蛇添足的模型;为你的预期听众所理解的模型;简单的模型;足够正确、足够一致、足够详细的模型;创建和维护它的投资能够给项目提供正面价值的模型。

    一个普遍的哲学问题是源代码是不是一个模型,更重要的,它是不是一个敏捷模型。如果你是在我们这篇文章之外问我这个问题,我会回答说,是,源代码是一个模型,虽然是一个高度细节化的模型,因为它是软件的一个抽象。同时我还认为,优秀的代码是一个敏捷模型。但在这里,我还需要把两者区分开来,源代码和敏捷模型还是有区别的——敏捷模型帮助你得到源代码。

    敏捷开发建模者

    敏捷建模者的个性

    Alistair Cockburn指出:很多的方法学都定义了软件开发项目中开发人员所担任的角色,同时还定义各个角色执行的任务,尽管入席,这些方法并没有定义这些角色最适合的人选。一个人要想成功的担任某个角色,他应当很好的适应它--虽然这并不需要人们掌握所有的技能,但人们必须要慢慢的熟悉这些技术。我的经验告诉我,要成为一个成功的敏捷建模者,下面的列出的个性是必要的:

    团队竞赛

    第一点,也是最重要的一点,敏捷建模者总是积极的寻求协作,因为他们意识到他们不是万事通,他们需要不同的观点,这样才能做到最好。软件开发可不是游泳,单干是非常危险的。在敏捷的字典中没有“我”这个词。

    畅所欲言

    敏捷建模者都有良好的沟通技巧--他们能够表达出他们想法,能够倾听,能够主动获取反馈,并且能够把需要的写出来。

    脚踏实地

    敏捷建模者应当脚踏实地 他们的精力都集中在满足用户的需求上,他们不会在模型上画蛇添足,即便那双足是多么的好看。他们满足于提供可能的方案中最简单的一种,当然,前提是要能够完成工作。

    好奇

    敏捷建模者乐衷于研究问题,解决问题。

    凡是都问个为什么

    敏捷建模者看问题从不会至于表面,而是会打破沙锅问到底。他们从不会就想当然的认为一个产品或一项技术和它们的广告上说的那样,他们会自己试一试。

    实事求是

    敏捷建模者都非常的谦逊,他们从不认为自己是个万事通,所以他们会在建立好模型之后,用代码来小心的证明模型的正确。

    根据实验

    敏捷建模者应当愿意尝试新的方法,例如一项新的(或是已有的)建模技术。一般而言,他们也会接受敏捷建模开发技术,必要时,为了验证想法,他们愿意同传统的思想做斗争,例如在一个项目中减少文档数量。

    有纪律

    要坚持不懈的遵循敏捷建模的实践。对你来说,你可能会在不经意间说,“加上这个功能吧!无伤大雅。”或是,“我比project stakeholder更了解。”在AM的道路上要想不偏离方向,是需要一定的纪律性的。

    敏捷开发建模误区

    走出一般性的设计误区,迈向成功之途 无论你遵从的是重量级的方法,比如Enterprise Unified Process(EUP),还是轻量级的开发过程,如Extreme Programming(XP),建模在软件开发中都是不可或缺的。但不幸的是其中充斥着各种谬误与迷思。这来自于各个方面,有从理论家错误的研究、数十年来信息技术领域内的文化沉积、软件工具开发商天花乱坠般的市场宣传以及象Object Management Group (OMG)和IEEE这类组织的标准。下面,我们要揭示建模中的误区,指出其相应的事实真相。

    误区一

    建模就等于是写文档

    这很可能是其中最具破坏力的一条,因为开发人员可以此为借口而完全放弃建模。许多优秀的软件开发人员会说他们不想把时间浪费在这些“无用的“文档上。他们沉溺于编码之中,制造着一些脆弱而劣质的系统。

    事实分析:“模型”与“文档”这二者在概念上是风马牛不相及的—你可以拥有一个不是文档的模型和不是模型的文档。一幅设计图就是一个模型,而不论是被画在餐巾纸的背面,或写在一块白板上,或在Class Responsibility Collaboration(CRC)卡片中,还是根据记录在报纸和便签纸上的流程图而生成的一个粗略的用户界面原型。虽然这些都不能说是文档,但他们却都是有价值的模型。

    建模很象是作计划:作计划的价值在于计划编制的过程中,而非计划本身;价值体现在建模的活动中,而非模型本身。实际上,模型不是你系统中的一部分正式的文档,而且在完成它们的使命后可以被丢掉。你会发现值得保留的只有很少的模型,而且它一定是非常完美。

    误区二

    从开始阶段你可以考虑到所有的一切

    这种说法流行于二十世纪七十年代到八十年代早期,现今的许多经理都是在那个时候学习的软件开发。对这一点的迷信会导致在前期投入可观的时间去对所有的一切建模以期把所有一切都弄正确,试图在编码开始前就“冻结”所有的需求(见误区四),以致于患上“分析期麻痹症” – 要等到模型非常完美之后才敢向前进。基于这个观点,项目组开发了大量的文档,而不是他们真正想要得到的—开发满足需要的软件。

    事实分析:怎么才能走出这个误区呢?首先,你必须认识到你不能考虑到所有的细枝末节。第二,认识到编码员可能会对建模者的工作不以为然(这是可能的,事实上建模者所作的工作在实际价值中只占很少的部分),他们或许会说模型没有反应出真实的情况。第三,认识到不管你的最初所作的规格说明书有多好,但注定代码会很快地与之失去同步,即便是你自己建模自己编码。一个基本的道理就是代码永远只会和代码保持一致。第四,认识到迭代法(小规模地建模,编一些代码,做一些测试,可能还会做一个小的工作版本)是软件开发的准则。它是现代重量级的软件开发过程(如EUP),以及轻量级(如XP)的基本原理。

    误区三

    建模意味着需要一个重量级的软件开发过程

    走入这个误区(经常与误区一有联系)的项目组常常是连建模都彻底地放弃了,因为这样的软件开发过程对他们来说太复杂太沉重了。这不亚于一场天灾。

    事实分析:你可以用一种敏捷的方式取而代之。关于用简单的工具进行简单地建模的详细内容可参看Agile Modeling(AM)。而且,你可以丢弃你的模型当使命完之后,同样也可以很基本的方式进行建模(比如,从办公桌起来,来到白板前就开始构略草图)。只要你愿意,你就可以轻松地建模。

    误区四

    必须“冻结”需求

    这个要求常常来自高级经理,他们确切地想知道他们从这个项目组能得到什么东西。这样的好处就是在开发周期的早期确定下需求,就可以确切地知道所要的是一个什么样的东西;缺点就是他们可能没有得到实际上所需要的。

    事实分析:变化总会发生的。由于优先级的变化和逐渐对系统有了更进一步的理解,都会引起需求的变化。与冻结需求相反,估计项目成功的风险,尽量去接受变化而且相应地采取行动,就象XP所建议的一样。

    误区五

    设计是不可更改的

    如同误区四,要求每一个开发人员必须严格遵从“设计“,导致开发人员为了符合“设计“而作了错误的事情或以错误的方式作正确的事情。或者是简单地忽略了设计,否定了所有设计可能带来的好处。冻结了设计,你就不能从在项目进程中所学到知识进一步获益。另外一个很大的趋势就是开发出大量的文档而不是实际的软件,使用面向文档的CASE工具而不是能给项目带来实际价值的面向应用的工具。

    事实分析:事实上,设计会经常根据开发人员和数据库管理员的反馈进行修改,因为他们是最接近实际应用的人,通常他们对技术环境的理解要好于建模者。我们必须的面对这样一个事实:人无完人,他们所作的工作也不可能尽善尽美。难道您真的想将一个并不完善的设计固定下来而不再去修改其中的错误吗?另外,如果需求并没有被冻结,其实就意味着你不能冻结你的设计,因为任何需求的修改势必影响设计。对之,正确的态度是:只要你的代码还在改动,设计就没完。

    误区六

    必须使用CASE工具

    建模常常被认为是一项复杂的工作,因此需要大量地使用CASE工具辅助进行。

    事实分析:是的,建模可以是很复杂的。但你完全可以建立一个有效而简单的模型表述其中关键的信息,而不是将一些无关紧要的细节包括进来。

    误区七

    建模是在浪费时间

    许多新手都这样认为,这主要是因为他们所接受的教育仅仅局限于如何编写代码,对于完整的开发流程鲜有接触。而且他们的经验也仅限于如何实现代码,就如初级程序员。他们放弃了提高效率和学习技能的机会,这些技能能够使他们很容易地适应不同的项目或组织。他们应该为此感到羞愧。

    事实分析:在大多数情况下,在开始编码之前画一个草图、开发一个粗率的原型或者制作一些索引卡片都能提高你的生产效率。高效的开发者在编码之前都要进行建模工作。另外,建模是一种很好的在项目组成员与项目负责人之间沟通途径。你们在这个过程中探讨问题,从而对所要的是一个什么样的东西可以得到更好的理解,涉及到该项目中的每个成员也可得到对该项目有一个充分的了解。

    误区八

    数据模型(Data Model)就是一切

    许多组织基于数据模型就蹒跚启动新的开发工作,也许正如你所在的组织:IT部门对于数据有非常严格的规定,控制着你的开发项目;或者你以前的数据库是一团糟,别无选择。

    事实分析:数据模型是一个重要的但不是最重要的建模,它最好是建立在另外的模型之上。(参见“Extreme Modeling”,Thinking Objectively,Nov.2000)。这即使在象数据仓库这类面向数据的项目中也如此。如果没有很好的理解用户是如何使用该数据仓库的(在数据模型中没有表示出来),这些项目经常是以可悲的失败而告终。你可以使用的模型有很多 – 使用案例(use cases),业务规则(business rules),activity diagrams,类图(class diagrams),component diagrams,用户界面流程图(user interface flow diagrams)和CRC,等等。数据模型仅仅是其中的一种。每种模型都有其长处和短处,应该正确地使用。

    误区九

    所有的开发人员都知道如何建模

    面临这样一个严重的问题:许多不是开发人员的人,不知道软件是如何建成的。其结果,他们不能够区分开熟练的开发者和一般的程序员(当然也分不清高级程序员和一般程序员),他们想当然地认为所有的开发人员都具备从头到尾开发整个系统的技能。

    事实分析:这肯定是不正确的。建模的技能,是只有当一个开发者通过学习它,并经过长期的实践才能够掌握。一些非常聪明的程序员常常相信自己无所不能,毕竟他们终究只是程序员。正因为这样的狂妄自大,他们承当的一些任务是他们根本就没有相应的技能去完成的。软件开发是如此的复杂,单单一个人是很难具备所有的技能去成功地进行开发,甚至也不可能去配置有一定复杂程度的系统。开发者应该有自知之明,明白他们自己的弱点,学无止境。通过互相取长补短,建模者可从程序员身上学到一项技术的具体细节,程序员也可从建模者那里学到有价值的设计和体系结构的技术。我个人认为所有的人,包括我自己,都是新手。

    敏捷开发宣言

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

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

    客户合作 胜过 合同谈判

    响应变化 胜过 遵循计划

    虽然右项也有价值,但是我们认为左项具有更大的价值。

    敏捷开发遵循原则

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

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

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

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

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

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

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

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

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

    简单是最根本的。

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

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

    当软件开发随需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。

    n 僵化性:很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。

    n 脆弱性:对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

    n 牢固性:很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。

    n 粘滞性:做正确的事情比做错误的事情要困难。

    不必要的复杂性:设计中包含有不具任何直接好处的基础结构。

    n 不必要的重复性:设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。

    晦涩性:很难阅读、理解。没有很好地表现出意图。

    敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。

    为了改变上面软件设计中的腐化味,敏捷开发采取了以下面向对象的设计原则来加以避免,这些原则如下:

    单一职责原则(SRP)

    就一个类而言,应该仅有一个引起它变化的原因。

    开放-封闭原则(OCP)

    软件实体应该是可以扩展的,但是不可修改。

    n Liskov替换原则(LSP)

    子类型必须能够替换掉它们的基类型。

    n 依赖倒置原则(DIP)

    抽象不应该依赖于细节。细节应该依赖于抽象。

    n 接口隔离原则(ISP)

    不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。

    n 重用发布等价原则(REP)

    重用的粒度就是发布的粒度。

    共同封闭原则(CCP)

    包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。

    共同重用原则(CRP)

    一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。

    环依赖原则(ADP)

    在包的依赖关系图中不允许存在环。

    稳定依赖原则(SDP)

    朝着稳定的方向进行依赖。

    稳定抽象原则(SAP)

    包的抽象程度应该和其稳定程度一致。

    上述中的包的概念是:包可以用作包容一组类的容器,通过把类组织成包,我们可以在更高层次的抽象上来理解设计,我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分,然后把那些划分后的类分配到包中。

    敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

    敏捷开发团队原则

    最大的分歧

    最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员,测试人员被期望能编写一点代码,同时开发人员可以做一些测试。各自的强项还是很重要:新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试,开发人员大都编写代码,但所有人都分享他们的工作,而且有能力承担他们面前的任务。

    发现中立点

    团队决定作为一个团队需要做什么,如何最好地分配工作。第一步是让团队成员说说他们自己的技能集、优点和缺点。但却不希望他们根据以前角色(如,软件测试员或开发员)来定义自己。所以找到一个中立点,她列出了小型离线会议,和每周工作之外的小时集体活动所需的事项。这样,该团队去当地的农场采摘蓝莓。他们一起上瑜珈课。他们集体在厨房里烤燕麦棒,做果沙。

    正确执行应用程序

    团队找到了让自此感到舒服的新水平。整个项目的工作流程顺利进行,只做一个待办的事情,而不是四个。

    分布式敏捷开发

    分布式敏捷开发团队并不是工作在所有组织中;拥有一个已经建立的分布式敏捷开发工作文化对分布式团队很重要。有些公司一直坚持“面对面”,这给分布式敏捷站立会议的开发增加的难度。

    但是如果文化一直就已经存在,那么开展敏捷站立会议和其它会议就会很容易。其中的一个选择就是使分散的团队成员按照同一计划表工作,即时区不一致。如果团队成员同意,且时差不超过几个小时的话,这才有效。

    敏捷开发的原则

    1. 快速迭代

    相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加简单快速。一些公司,一年发布仅2~3个版本,发布流程缓慢,它们仍采用瀑布开发模式,更严重的是对敏捷开发模式存在误解。

    2. 让测试人员和开发者参与需求讨论

    需求讨论以研讨组的形式展开最有效率。研讨组,需要包括测试人员和开发者,这样可以更加轻松定义可测试的需求,将需求分组并确定优先级。 同时,该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。

    3. 编写可测试的需求文档

    开始就要用“用户故事”(User Story)的方法来编写需求文档。这种方法,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早的提及技术实施方案,会降低对需求的注意力。

    4. 多沟通,尽量减少文档

    任何项目中,沟通都是一个常见的问题。好的沟通,是敏捷开发的先决条件。在圈子里面混得越久,越会强调良好高效的沟通的重要性。

    团队要确保日常的交流,面对面沟通比邮件强得多。

    5. 做好产品原型

    建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档,但人人都会看图。

    6. 及早考虑测试

    及早地考虑测试在敏捷开发中很重要。传统的软件开发,测试用例很晚才开始写,这导致过晚发现需求中存在的问题,使得改进成本过高。较早地开始编写测试用例,当需求完成时,可以接受的测试用例也基本一块完成了。 

    敏捷开发概述

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


      
    Image:敏捷开发的路线图.jpg

    敏捷开发的路线[1]

      图:敏捷开发的路线图

      Test-Driven Development,测试驱动开发

      它是敏捷开发的最重要的部分。在ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解为一个一个的Story,记录在Story Card上。然后两个人同时坐在电脑前面,一个人依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。

      Continuous Integration,持续集成。

      在以往的软件开发过程中,集成是一件很痛苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。在我们公司里,开发人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快定位失败原因从而让灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseControl。

      Refactoring,重构。

      相信大家对它都很熟悉了,有很多很多的书用来介绍重构,最著名的是Martin的《重构》,Joshua的《从重构到模式》等。重构是在不改变系统外部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前,都要对所写代码进行重构,让代码达到clean code that works。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证重构是否引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重构。

      Pair-Programming,结对编程。

      在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如Pair学习,Pair翻译,Pair做PPT,关于这个话题,钱钱同学有一篇很有名的文章对它进行介绍,名为Pair Programming (结对编程)。

      Stand up,站立会议。

      每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等,而是每个人都回答三个问题:1. 你昨天做了什么?2. 你今天要做什么? 3. 你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和你进行讨论。

      Frequent Releases,小版本发布。

      在敏捷开发中,不会出现这种情况,拿到需求以后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所以客户有新的需求或者需求进行变动,也能很快的适应。

      Minimal Documentation,较少的文档。

      其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。

      Collaborative Focus,以合作为中心,表现为代码共享。

      在敏捷开发中,代码是归团队所有而不是哪些模块的代码属于哪些人,每个人都有权利获得系统任何一部分的代码然后修改它,如果有人看到某些代码不爽的话,那他能够对这部分代码重构而不需要征求代码作者的同意,很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码,即使团队的人员变动,也没有风险。

      Customer Engagement ,现场客户。

      敏捷开发中,客户是与开发团队一起工作的,团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后,能够以最快速度得到客户的反馈。

      Automated Testing ,自动化测试。

      为了减小人力或者重复劳动,所有的测试包括单元测试、功能测试或集成测试等都是自动化的,这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具,能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作,包括Selenium开源项目。

      Adaptive Planning,可调整计划。

      敏捷开发中计划是可调整的,并不是像以往的开发过程中,需求分析->概要设计->详细设计->开发 ->测试->交付,每一个阶段都是有计划的进行,一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代,小版本的发布,根据客户反馈随时作出相应的调整和变化。

      敏捷开发过程与传统的开发过程有很大不同,在这过程中,团队是有激情有活力的,能够适应更大的变化,做出更高质量的软件。

      (1)敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

      这里说的预设性,可以通过一般性工程项目的做法理解,比如土木工程,在这类工程实践中,有比较稳定的需求,同时建设项目的要求也相对固定,所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分,施工队伍可以完全遵照图纸顺利建造,并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

      然而,在软件开发的项目中,这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定,从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发。所以,这类方法在不可预测的环境下,很难适应变化,甚至是拒绝变化。

      与之相反的敏捷方法则是欢迎变化,目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。所以称之为适应性方法。      (2)敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

      Matin Flower认为:“在敏捷开发过程中,人是第一位的,过程是第二位的。所以就个人来说,应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

      在传统的软件开发工作中,项目团队分配工作的重点是明确角色的定义,以个人的能力去适应角色,而角色的定义就是为了保证过程的实施,即个人以资源的方式被分配给角色,同时,资源是可以替代的,而角色不可以替代。

      然而,传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点,充分发挥人的创造能力。

      敏捷开发的目的是建立起一个项目团队全员参与到软件开发中,包括设定软件开发流程的管理人员,只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策,因为他们是最了解什么技术是需要和不需要的。再者,敏捷开发特别重视项目团队中的信息交流,有调查显示:“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”


      实际上敏捷开发运动在数年前就开始了,但它正式开始的标志是2001年2月的“
    敏捷宣言”(Agile Manifesto),这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的,他们的价值观是:个人与交互重于开发过程与工具;可用的软件重于复杂的文档;寻求客户的合作重于对合同谈判;对变化的响应重于始终遵循固定的计划。

    敏捷开发的价值观

      个人与交互重于开发过程与工具的原因:一个由优秀的人员组成但使用普通的工具,要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程,以便把人当作机器上的一个可以替代的齿轮,但结果却并不成功。敏捷过程是承认每个人都有特定的能力(以及缺点)对之加以利用,而不是把所有的人当成一样来看待。更重要的是,在这样的理念下,几个项目做下来,每个人的能力都从中得以提高。这种人的能力的提高,对公司是无价之宝。而不至于把人当成齿轮,随着时间的推移,人的能力慢慢被消耗掉,最后变成留之无用、弃之可惜的尴尬人物。

      可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候,获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始,并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长,以保证开发小组始终是处理最有价值的功能,而且这些功能可以满足用户的期待。

      寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力,合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢,要么大家一起输。换句话说,就是希望开发小组和客户在面对项目的时候,以一种合作的态度共同向目标前进。当然,合同是必需的,但是如何起草条款,往往影响到不同的团体是进行合作式的还是对抗式的努力。

      对变化的响应重于始终遵循固定的计划的原因:敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外,用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法,也许今天看起来是必需的功能,明天就会觉得不那么重要了。随着小组获得更多的知识和经验,他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说,一个计划是从某个角度对未来的看法,而具有多个不同的角度看问题是有可能的。

    项目的敏捷开发方法

      敏捷方法很多,包括 Scrum极限编程、功能驱动开发以及统一过程(RUP)等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。下图是典型的敏捷过程总图,下面介绍其有关的特点。

      Image:敏捷过程总图.gif

      1、敏捷小组作为一个整体工作

      项目取得成功的关键在于,所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员;编码人员也不会把只经过部分测试的代码“扔”给测试人员,一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”, “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然,尽管强调一个整体,小组中应该有一定的角色分配,各种敏捷开发方法角色的起名方案可能不同,但愿则基本上是一样的。第一个角色是产品所有者,他的主要职责包括:确认小组成员都在追求一个共同的目标前景;确定功能的优先等级,以便总是处理最有价值的功能;作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员,在开发内部使用的软件的时候,产品所有者可能是用户、用户的上级、分析师,也可能是为项目提供资金的人。

      2、敏捷小组按短迭代周期工作

    在敏捷项目中,总体上并没有什么上游阶段、下游阶段,你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计,但只要项目真正开始,每次迭代都会做同样的工作(分析、设计、编码、测试。等等)。迭代是受时间框限制的,也就是说即使放弃一些功能,也必须结束迭代。时间框一般很短,大部分是 2~4周,在 Scrum中采用的是 30个日历天,也就是 4 周。迭代的时间长度一般是固定的,但也有报告说,有的小组在迭代开始的时候选择合适的时间长度。

      3、敏捷小组每次迭代交付一些成果

      比选择特定迭代长度更重要的,是开发小组在一次迭代中要把一个以上的不太精确的需求声明,经过分析、设计、编码、测试,变成可交付的软件(称之为功能增量)。当然并不需要把每次迭代的结果交付给用户,但目标是可以交付,这就意味着每次迭代都会增加一些小功能,但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要,但这并不意味着要完成发布的全部工作,因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”(MTBF)测试,他们不可能缩短这两个月的时间,但这个小组仍然是按照 4 周迭代,除了MTBF测试,其它都达到了发布状态。

      4、敏捷小组关注业务优先级

      敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先,他们按照产品所有者制定的顺序交付功能,而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级,并且把它组织到产品发布中去。要达到这个目的,需要综合考虑开发小组的能力,以及所需功能的优先级来建立发布计划。在编写功能的时候,需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能,那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的,但把功能依赖性控制在最低程度还是相当可行的。

      5、敏捷小组检查与调整

      任何项目开始的时候所建立的计划,仅仅是一个当前的猜测。有很多事情可以让这样的计划失效:项目成员的增减,某种技术比预期的更好或更差,用户改变了想法,竞争者迫使我们做出不同的反应,等等。对此,敏捷小组不是害怕这种变化,而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始,敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性,也可能更改计划。比如发现某项工作比预计的更耗费时间,可能就会调整进展速度。也许,用户看到交付的产品后改变了想法,这就产生反馈,比如他发现他更希望有另一项功能,或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能,或者减少某些低价值功能,就可以增加产品的价值。迭代开发是在变与不变中寻求平衡,在迭代开始的时候寻求变,而在迭代开发期间不能改变,以期集中精力完成已经确定的工作。由于一次迭代的时间并不长,所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身,对于项目投资最大化是有益处的。从这个观点来看,迭代周期的长度选择就比较重要了,因为两次迭代之间是提供变更的机会,周期太长,变更机会就可能失去;周期太短,会发生频繁变更,而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑,对于一个复杂项目,迭代周期选择4周还是有道理的。

      MIT Sloan Management Review(麻省理工学院项目管理评论)所刊载的一篇为时两年对成功软件项目的研究报告,报告指出了软件项目获得成功的共同因素,排在首位的是迭代开发,而不是瀑布过程。其它的因素是:

      1、至少每天把新代码合并到整个系统,并且通过测试,对设计变更做出快速反应

      2、开发团队具备运作多个产品的工作经验。

      3、很早就致力于构建和提供内聚的架构。

      从这个报告中所透露出的信息告诉我们,认真研究敏捷过程对软件项目的成功是非常有意义的,它的意义在于:

      1)给开发小组的自组织提供了机会

      经典项目管理就好比一个具备中央调度服务的航空管理系统,这个系统是自治的,而且是封闭的,但现实中更庞大的系统,似乎并不属于中央调度控制系统,但也同样也是有效的。假如我们开车到某个地方,我们可以任意选择所需要的路线,我们甚至不需要准确计算停车,只要我们遵守交通法规,驾驶员可以临时根据路况改变某个转弯点,在驾驶游戏规则的框架内,依照自身最大利益做出决策。成千上万的驾驶者,并不需要中央控制和调度服务,人们仅仅在简单的交通法规的框架内,就可以完成综合起来看是更庞大的目标,很多事情从管理的角度只要抓住关键点,并不需要多么复杂的规则,往往会更有效。随着系统复杂度的提高,中央控制和调度系统面临崩溃。仔细研究交通系统的特点,我们会发现这样的系统中独立的个体在一组适当的规则下运行,并不需要设计每个个体临时变更的方案,而每个个体只需要知道目标和大致的状况,他们完全可以利用自己的聪明才智来决定自己的行为。

      2)缩短了反馈通道

      敏捷过程有效运作的另一个原因是,它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候,便需要有一种方法在比较短的时间内发展完善。事实上,所有的过程改进都不同程度的使用着戴明循环,以研究问题、测试解决方案、评估结果,进而根据已知的事实来进行改进,这就称之为基于事实的决策模式,我们都知道,这比前端预测的决策方式更加有效。

      3)易于集思广益

      敏捷过程能有效应用的另一个原因在于,它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候,总有某些人员知道问题所在,但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸,事后分析出了各种原因,但这种调查也提供给我们一个惊人的事实,就是部分工程师早就意识到这些潜在问题,却无法说服他人重视这个担忧。对这些事实的深入思考,促使我们研究我们应该采取何种管理系统,使前线工作人员的经验、观点及担忧得到充分的重视呢?

    [

    对敏捷开发的误解

      误解一:敏捷对人的要求很高

      很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么? 软件归根到底还是一种创造性活动,开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用,各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作,从而产生更高的生产力。不管用什么方法,开发人员的水平永远都是一个主要的因素。

      从另一个角度来看:过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员,敏捷方法和传统方法对他的帮助是差不多的,因此看不到显着的效果,甚至有些时候还有反效果;而随着开发人员技术水平的提高,敏捷方法能够解开对人的束缚,鼓励创新,效果也会越来越显着。

      敏捷对人的要求并不高,而且会帮助你培养各种所需的能力,当然前提是你处在真正敏捷的环境中。

      误解二:敏捷没有文档,也不做设计

      这个误解从XP开始就没有停止过,XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准,并不是所有的文档都不写。例如,用户手册是不是“必要且意义重大”?这取决于客户的要求,如果客户不需要,那就不用写,如果客户需要,就一定要写;再如,架构设计文档要不要写?复杂要写,不复杂不用写。通常架构设计只需要比较简单的文档,对于有些项目,一幅简单的UML图就够了。因此,写不写,怎么写,都要根据这个文档到底有多大意义,产出和投入的比例,以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定,尽量避免由某一个人(比如lead)来决定。

      至于设计,XP奉行的是持续设计,并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中,不断的设计、改善(重构),使得设计一直保持灵活可靠。至于编码前的预先设计,Kent Beck等人确实实行着不做任何预先设计的开发方式,但是对于我们这些“非大师”级开发人员,必要的预先设计还是需要的,只是不要太多,不要太细,要有将来会彻底颠覆的准备。

      误解三:敏捷好,其他方法不好

      有些人一提到敏捷就大呼好,只要是敏捷的实践就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上边就哪里都不好,似乎敏捷和其他方法是完全对立的。牛顿说过,我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点,也是站在了巨人的肩膀上,敏捷依然保持了很多历史悠久的实践和原则,只是表现方式不同罢了。

      从另一个方面来看,方法本没有好环,好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境,在需求稳定、软件复杂度相对不高的时代,瀑布模型也可以工作的很好,而敏捷恰好适用于变化快风险高的项目 - 这恰恰是现在很多项目的共性。

      因此选择一个方法或过程,并不是根据它是否敏捷,而应根据它是否适合。而要了解一个东西是否适合,还是要尝试之后才知道,任何没有经过实践检验的东西都不可信。

      误解四:敏捷就是XP(极限编程),就是Scrum

      XP 和Scrum只是众多敏捷方法中的两种,还有很多其他的敏捷方法。龙生九子各个不同,敏捷的这些方法看起来差别也是很大的,可是他们之所以被称为敏捷方法,就是因为他们背后的理念和原则都是相同的,这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践,还要理解实践后的原则,不仅要理解怎么做,还要理解为什么这么做,以及什么时候不要这么做。

      即使将XP或Scrum完全的应用的你的项目中,也未见得就能成功,适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点,但绝对不是终点,最适合你的方式还要由你自己在实际工作中探索和寻找。

      误解五:敏捷很好,因此我要制定标准,所有项目都要遵循着个标准

      没有哪两个项目是一样的,客户是不一样的,人员是不一样的,需求是不一样的,甚至没有什么可能是一样的。不一样的环境和问题,用同样的方法解决,是不可能解决的好的。方法是为人服务的,应该为项目团队找到最适合他们的方法,而不是先确定方法,再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

      同时,对于同一个团队,随着项目的进行,对需求理解的深入,对技术理解的深入,一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整,保证项目的质量和效率。敏捷是动态的,而非静止不变的,因为这个世界本身就是变化的,在变化的世界使用不变的方法,是不现实的。银弹从来就没有过,在有限的将来也不会存在。


    敏捷开发知识体系整体框架

    敏捷开发工程实践

    项目管理

    • 迭代开发
    • 风险价值生命周期
    • 多级项目规划
    • 完整团队
    • 每日站立会议
    • 任务板
    • 燃尽图

    需求管理

    • 需求订单
    • 业务流程草图
    • 用例驱动开发
    • 用户故事

    架构

    • 演进的架构
    • 演进的设计
    • 基于组件的架构设计

    开发

    • 结对编程
    • 测试驱动开发
    • 重构
    • 代码规范

    测试

    • 单元测试
    • 并行测试
    • 测试管理

    变更管理

    • 持续集成
    • 自动构建
    • 团队变更管理

    敏捷开发管理实践描述

    • 定义和特征说明
    • 主要角色
    • 主要活动和最佳实践
    • 主要输入输出
    • 工作流程

    敏捷开发工程实践描述

    • 定义和特征说明
    • 应用说明
    • 案例说明

    敏捷开发核心价值观和原则

    敏捷软件开发宣言

    个体和互动 高于 流程和文档
    工作的软件 高于 详尽的文档
    客户合作 高于 合同谈判
    响应变化 高于 遵循计划
    也就是说, 尽管右项有其价值, 我们更重视左项的价值.
    • 1
    • 2
    • 3
    • 4
    • 5
    • 1
    • 2
    • 3
    • 4
    • 5

    敏捷软件开发的核心价值观

    敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

    核心价值观

    • 以人为本
    • 目标导向
    • 客户为先
    • 拥抱变化

    敏捷开发的原则

    • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
    • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
    • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
    • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
    • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
    • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
    • 可工作的软件是进度的首要度量标准。
    • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
    • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
    • 以简洁为本,它是极力减少不必要工作量的艺术。
    • 最好的架构、需求和设计出自自组织团队。
    • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    敏捷开发管理实践

    Scrum

    Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

    Scrum中的角色

    “猪”角色

    • 产品负责人(Product Owner) 
      • 通常由市场部门的人担任
    • 敏捷教练 (Scrum Master) 
      • 通常由开发组组长担任
    • 开发团队 (Scrum Team) 
      • 包括开发,需求,测试

    “鸡”角色

    • 用户 
      • 软件是为了某些人而创建!就像“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗”,“假如软件没有被使用,那么它算是被开发出来了么?”
    • 利益所有者 (客户,提供商) 
      • 影响项目成功的人, 但只直接参与冲刺评审过程。
    • 管理者 
      • 为产品开发团体架起环境的那个人

    主要活动和最佳实践

    • 迭代式软件开发
    • 两层项目规划 (Two-Level Project Planning)
    • 整体团队协作 (Whole Team)
    • 持续集成
    • 冲刺规划会议 (Sprint Plan Meeting)
    • 每日站立会议 (Sprint Daily Meeting)
    • 冲刺复审会议 (Sprint Review Meeting)
    • 冲刺回顾会议 (Retrospective Meeting)

    scrum方法中得主要活动和交付件

    主要输入输出

    • 产品订单(Product Backlog)
    • 冲刺订单(Spring Backlog)
    • 燃尽图(Burndown Chart)
    • 新的功能增量

    工作流程

    scrum方法全景图

    项目管理过程

    • 在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.
    • 产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

    项目开发过程

    在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

    • 在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)
    • 产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.
    • 在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.
    • 在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.
    • 在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

    XP

    OpenUp

    Lean

    敏捷开发工程实践

    迭代式开发

    敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

    持续集成

    持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

    多级项目规划

    多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

    • 项目/产品愿景
    • 项目/产品路线图
    • 版本发布计划
    • 迭代计划
    • 每日实现

    项目/产品愿景

    在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

    • 当前的问题
    • 机会描述和理由(描述项目的重要性)
    • 项目的价值
    • 项目如何和组织的战略目标达成一致
    • 解决方案综述
    • 项目包含的关键功能
    • 项目必须服从的技术和约束条件
    • 项目范围
    • 项目的关键时间线
    • 项目收益分析
    • 项目和其他项目的依赖性
    • 项目的相关风险以及如何消除

    项目/产品路线图

    主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

    版本发布计划

    版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

    迭代计划

    迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

    • 根据当前状态确定是否需要对版本计划做出更新
    • 为当前的迭代计划制定迭代计划

    迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

    每日实现

    没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

    完整团队

    Scrum团队必须具备的三个完整性:

    团队职责完整性

    产品负责人(Product Owner)

    • 确定产品的功能。
    • 决定发布的日期和发布内容。
    • 为产品的收益(profitability of the product)负责。
    • 根据市场价值确定功能优先级。
    • 在30天内调整功能和调整功能优先级。
    • 接受或拒绝接受开发团队的工作成果

    敏捷教练 (Scrum Master)

    • 负责监督整个Scrum项目进程, 调整开发计划
    • 保证团队资源完全可被利用并且全部是高产出的。
    • 保证各个角色及职责的良好协作。
    • 解决团队开发中的障碍。
    • 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
    • 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
    • 需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图
    • 需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍
    • 个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清,或通过内部的沟通解决,或向管理层和HR寻求帮助解决
    • Scrum Master需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
    • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

    开发团队 (Scrum Team)

    • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
    • 弱化分工, 每个人都参与设计, 开发与测试
    • 确定Sprint目标和具体说明的工作成果。
    • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
    • 向Product Owner演示产品功能。

    团队素质完整性

    • 要具备很强的集体协作精神.
    • 要具备良好的沟通能力
    • 必须能积极主动的接受新的事物, 要具备创新能力
    • 要具备极强的自我管理能力和积极主动的精神

    沟通的完整性

    • Sprint启动会
    • 每日站立会议
    • Sprint回顾会

    案例

    验收测试驱动开发ATDD

    TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

    • 挑选用户故事
    • 为故事写测试
    • 实现测试
    • 实现故事

    结对编程

    结对编程可以看做是一种敏捷化的Code Review

    新结对编程

    两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

    确定冲刺计划

    定义和说明

    • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
    • 主要角色: ST, PO, SM
    • 主要输入: Product backlog, 团队的能力
    • 主要输出: Sprint Backlog

    冲刺会议分两个部分 
    1. 解决本次冲刺要完成哪些需求 
    2. 解决这些选择的需求要如何被完成

    案例

    故事点估算

    故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

    计划扑克

    • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
    • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
    • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
    • 最高分和最低分的组员像团队做出解释
    • 全组成员自由讨论几分钟
    • 重新打分, 直到全组统一.

    敏捷估算2.0(Agile Estmating 2.0)

    • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
    • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
    • 团队将故事点(Story Point)分配给每个故事.

    需求订单(Product Backlog)

    记录用户需求的列表, 包括产品所有需要的特征.

    • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
    • 需求订单式开放的, 团队每个成员都可以编写和维护
    • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

    燃尽图

    在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

    • 具备可视性
    • 具备风险预估, 提醒团队目前完成情况
    • 具备可估量, 直接显示当前还需要的时间.

    燃尽图常见问题

    每日站立会议(Daily Scrum)

    每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

    • 我们上次开会后你都干了什么
    • 在我们下次开会之前你要做什么
    • 每个你负责的、正在做的任务还剩下多少时间
    • 你的工作被阻碍了吗

    任务板(Task board)

    • 为项目团队提供一个便利的工具用于管理他们的工作
    • 是团队成员对本冲刺的工作一目了然

    任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

    用户故事卡

    每张卡片记录一条用户故事, 故事点.

    任务卡

    每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

    任务板的使用

    用户故事

    作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

    如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

    测试驱动开发(TDD)

    先开发测试用例, 然后再开发代码

    参考资料

    百度百科-敏捷开发:http://baike.baidu.com/link?url=cwuvVabLCt05za2V4avXDr1XWFUdiBlPeJWxxswQdacHZT76b_TZRGPGHFYEEn7aSGzx1sPeUm2TxthXiqcHTfAPjs15jvdQUn4wAHTOWdrKJd6dh-rA1fC-0BNy01hJ

    智库百科-敏捷开发:http://wiki.mbalib.com/wiki/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91

    敏捷开发知识体系笔记:http://blog.csdn.net/uxyheaven/article/details/49618097



    展开全文
  • 敏捷开发之道

    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。要是能把用例分析过程体现在源代码中就好了!


    展开全文
  • 谈谈敏捷开发模型

    2019-08-01 23:36:56
    随后进入了提倡敏捷开发的公司,被迫式的接触了许多“敏捷开发”,随着项目经历越来越多,慢慢的就开始有了更新的认识和想法。 但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更...
  • 敏捷”在互联网和软件开发领域从涓涓细流逐渐演变为行业潮流,往小了说是改进了开发方法,往大了说是革了瀑布流式的命——把产品开发引向了快速迭代、小步快跑的路线上。我们使用 tapd 写 feature,流转、跟踪任务...
  • 敏捷开发与敏捷测试

    2020-07-02 15:25:48
    敏捷开发:1.敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划,然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实,...
  • 使用Scrum框架进行敏捷开发,通过几个Sprint的磨练,每个Sprint都出现不能按时完成的Story,很是不爽! 1、对Story要完成的业务不清楚 2、对Story要使用的技术不清楚 3、对Story之间的关联关系不清楚 4、对...
  • 敏捷开发

    2016-07-14 18:45:16
    敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此...
  • 项目敏捷开发

    2018-06-23 20:35:42
    敏捷开发是一项系统性的工作,需要根据团队特性量身定做,但仍然有一些普世的敏捷信条可以指导我们更加顺利地开展敏捷尝试。随着理解的深入,笔者会持续关注敏捷动态,为需要的好友们提供借鉴和思考。极限编程...
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...
  • 原型法和敏捷开发 原型法 定义:又称快速原型法,不属于敏捷开发。 根据需求用IDE实现基本功能,然后用户试用、补充和修改的重复过程,最后的版本再决定是demo还是正式版本。 分类 1. 抛弃型原型 - 此类原型在...
  • 有次去西安百度创业园谈项目,甲方直接丢了一句,我们需要敏捷开发。我们:放心,肯定高质量、短周期的交期。敏捷需要面对面沟通,随时沟通,计划紧凑,总之就是快准狠。 1、敏捷 敏捷软件开发宣言:个体和互动...
  • 敏捷开发的三个流程

    2017-08-07 10:45:42
    Scrum敏捷开发流程主要包扩三个角色、四个会议和三个物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。 Scrum 团队是自组织、跨职能的完整...
  • 目前软件开发业界已存在多种开发合作模式,各有其特点、适用性和局限性,没有一种开发...敏捷开发提到的相关原则,敏捷开发模式应用到实际开发过程中,实施起来或多或少与理论存在差异。所谓理论结合实际,作为开...
  • 笔者正在学习《软件工程-实践者的研究方法...敏捷可以应用于任何一个软件过程(沟通、策划、建模、构建和部署),过程的设计应该使项目团队适应于任务,并且使任务流水线化,在了解敏捷开发方法的流动性的前提下进行...
  • 敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此...
1 2 3 4 5 ... 20
收藏数 4,218
精华内容 1,687
关键字:

敏捷开发 跟踪长期的项目