2014-04-02 19:20:25 rechenwyj 阅读数 855
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

 

3.敏捷开发软件过程网

3.1标记扩展Petri

    文献【6】提出了一种描述软件过程模型的Petri网,本文在此基础上利用软件设计模式对软件过程网进行了扩展,使敏捷开发软件过程建模更严格清晰,并且避免了高级Petri网扩展的复杂性,可以使用以往的Petri网分析工具。本文定义了敏捷开发软件过程网及其属性,首先参考文献[7][8]给出标记扩展Petri网模型。

定义3.1

标记PETRI网:标记PETRI网是一个四元组N=PTFL),其中,

1P:有限库所集合,库所元素表示系统的状态也成为条件(图3.1)。

 

3.1 库所

2T:有限变迁集合,变迁元素也成为事件,事件的发生改变条件的状态(成真与否),引起信息在网上流动。且PT=PT(图3.2)。

 

3.2 变迁

3FFPTTP),为连接库所和变迁的有向弧线“”为笛卡尔积(图3.3)。

4domFcodF=PT,其中domF={x| y:(xyF}codF={y| x:(xy F}

 

3.3 有向弧

5LTA为标记函数,A为变迁的字符标记。

6N有两个特殊的库所(图3.4aN有两个特殊的变迁,其中={i}{}={o}·o={}

               

           图3.4   a(开始库所)               b(结束库所)           

7)如果在N上增加一个变迁连接oi,即·={o}={i}L=E,用表示,称N的扩展网,则为强连通的。

    ·t·p分别代表变迁和库所的前集和后集,(N)表示标示PETRI表示N的初始标示,M为定义在P上的多重集合,同时有MppPN。其他定义,如变迁规则,可达变迁,有限性,安全性等与经典PETRI网类似[8]

    在敏捷软件开发过程中我们使用用例图、依赖倒置、测试驱动、策略模式、模板方法、命令模式的软件设计模式来规范迭代过程,所以我们将模型中在普通的变迁之上增加了六类标记扩展的变迁即:基于用例图的变迁(图3.5a)、基于依赖倒置的变迁(图3.5b)、基于测试驱动开发的变迁(图3.5c)、基于策略模式的变迁(图3.5d)、基于模板方法模式的变迁(图3.5e)和基于命令模式的变迁(图3.5f)。

     

3.5   a.           b.            c.          d.          e.         f.

定义3.2 敏捷开发软件过程网:一个表示PETRISN=N,其中N=PTFL)称为敏捷开发软件过程网,当且仅当:T=,其中表示基于用例图变迁集,表示基于依赖倒置变迁集,表示基于测试驱动开发变迁集,表示基于基于策略模式的变迁集,表示基于模板方法模式的变迁集,表示基于命令模式的变迁集,表示基于依赖倒置、策略模式、模板方法和命令模式交的变迁集,表示在该变迁集中使用到这几种模式。

 

3.2变迁集说明

3.2.1基于用例图的变迁说明

根据素材形成用例图的过程中应合理使用各种用例关系,产生规范的用例图。下面对用例的基本关系作出的简单说明。

    (1)关联关系

    关联关系是用例执行者与用例之间的关系,如果某个执行者可以对某个用例进行操作,他们之间就具有关联关系。如图“用户”有一个功能为“添加产品”,因此可在执行者“用户”和用例“添加产品”之间建立一个关联关系。

 

4.1

    (2)包含关系

    如果多个用例都具有一部分相同的行为,可以将这部分相同的行为作为一个单独的用例抽象出来,与原来的用例形成了包含关系。如“用户”在添加、删除产品操作前需要先登录,登录是添加、删除流程的基本组成部分,因此“添加”和“删除”包含用例“登录”。包含关系能够更加清晰的描述多个用例的相同行为。

 

4.2

    (3)扩展关系

    如果一个用例在执行过程中可能会使用到另一个用例,或者使用一个新的用例对原有用例的行为进行扩展时可以使用扩展关系。如果一个用例在执行过程中可能会使用到另一个用例,或者使用一个新用例对原有的用例的行为进行扩展时可以使用扩展关系,如果“用户”在添加商品时发现该产品的分类信息不存在,则可以增加产品分类;如果该产品的分类已经存在则无需增加该产品分类,这时“添加产品分类”可以作为“添加产品”的扩展用例。

 

4.3

3.2.2基于依赖倒置原则的变迁说明

1)层次化设计

    “所有结构良好的面向对象架构都具有清晰的层次定义,每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。”[9]按照这个理解我们可以设计出类似图4.1所示的结构。

 

4.1

    如图所示高层的表示层ShoppingCart类使用了底层的业务逻辑层ValueCaculate类,而类ValueCaculate又使用了更低层的数据层ProductRepository类。这看起来貌似是符合逻辑的,但它却存在一个隐患:即表示层对于其下一直到数据层的改动都是敏感的。这种依赖还具有传递性,表示层依赖于某些依赖于数据层的层次,依次表示层传递性的依赖于数据层,这在敏捷开发过程迭代中是非常不好的。高层的模块包含了系统中的重要策略选择和业务模型,正是这些高层模块完成了需求所需要的功能,如果高层模块依赖于底层模块,那么对底层模块的改动就会直接影响到高层模块,从而迫使高层模块改动。这是不合乎逻辑的,应该是高层的实现需求的业务模型和策略选择的模块去影响底层细节实现模块的,高层模块应该优先并独立于包含细节实现的低层模块,不论怎么设计高层模块都不应该依赖于低层模块。但我们在平时的设计中还大量应用这种高层依赖低层的模式,在敏捷开发的迭代过程中需求改变时便很难及时地对高层的策略选择和业务模型进行改动,因为你在设计这些之前不得不优先考虑如何对其传递依赖的低层模块进行改动,以满足尚未实现的高层的需要,这时我们就需要一种设计模式来解除这种传递依赖关系。

 (2)依赖倒置原则

    图4.2展示了一种更为合适的层次化结构,每一个较高的层次都为它所需要的服务声明一个抽象接口,较低的层次实现了这些接口,每个高层类都通过该抽象接口使用下一层,这样高层就不依赖于低层,低层反而依赖于高层中声明的抽象服务接口。这不仅解除了Shopping类对于ValueCalculate类的依赖关系,也解除了对ProductRepository类的传递依赖关系。这不仅仅是依赖关系的倒置,也是接口所有权的倒置,高层类拥有抽象的接口,低层类则从这些接口中实现,通过这种倒置的接口所有权,对于业务逻辑层和数据层的所有改动都不会影响到表示层。 并且通过这种倒置的接口所有权,需求改变时便可以根据高层的策略选择和业务逻辑改变抽象的服务接口,低层模块则实现服务接口来对高层提供服务,这也符合我们由上至下的设计逻辑。我们敏捷开发过程产生的大多数类都是不稳定的,我们不想依赖于这些不稳定的类,通过对抽象的接口的依赖隔离了他们的不稳定性。根据依赖倒置原则我们创建了一个更容易迭代、更灵活的结构。

 

4.2

 

3.2.3基于测试驱动开发的变迁

测试驱动开发(test-driven development TDD[11],是由Kent Beck等提出的于传统的程序设计不同的方法。它将单元测试和程序设计有机地融合在一起,用单元测试来指导程序设计。

使用测试驱动开发的优势:

    (1)保证了代码设计的正确性,避免了过度设计保证了简洁性。

    编写单元测试不单是一种测试行为,更是一种设计行为。根据系统需求需要完成的功能设计单元测试,由测试来决定需要实现那些程序代码,即保证实现没有偏离设计的轨道,有保证了程序的简洁性。

    (2)提高代码质量,实现能编译的文档。

    敏捷开发由于缺乏对文档的重视一直为人所诟病,单元测试更是一种编写文档的行为。单元测试可以作为文档的一种很有价值的形式,如果想知道一个类中的函数是如何工作的,会有一个单元测试展示给你看。单元测试就像是一套使用说明,帮助其他程序员了解怎样使用代码,并且这种文档时可编译运行的,相对于普通文档有更强的说服力。

    (3)使用合适的测试模式和工具,简化设计实现过程。

    在测试的实现过程中使用Mock Object(模拟对象)的思想,它允许组件独立进行测试,可以通过模拟数据层进行独立的单元测试,不必实现一个真实的数据层,如图4.3所示。也就是说只要业务逻辑层实现了数据层的接口,就可以进行业务逻辑层的开发测试。

 

4.3

    我们选择开源的Mock moq作为模拟工具,它是使模拟更快、更简单的一个框架。它可以创建经过定制的模仿,只包含足以帮助我们进行测试的功能,避免了因为太过复杂的模仿实现而使工作无法进行。使用moq创建模仿有两个阶段,第一个阶段是创建一个新的Mock<T><T>代表泛型,即这里需要模仿的类型)。第二个阶段是建立该类型需要实现的动作。

3.2.4基于模板方法模式的变迁

    定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

    谈到基于模板方法模式的变迁,就要谈到继承的概念,早在20世纪90年代初期—也就是面向对象发展的初期人们就非常看重继承这个概念,继承关系蕴含的意义是非常深远的。

    使用继承我们可以基于差异编程,也就是说对于某一个满足了我们大部分需要的类,可以创建一个他的子类,并只改变其中我们不期望的部分,只是继承一个类,就可以重用该类的代码!通过继承,我们可以建立完整的软件结构分类,其中每一层都可以重用该层次以上的代码,这是一个美丽的新世界。

    关键技术:抽象类(abstract)的主要目的是为它的子类定义公共接口。一个抽象类将把它的部分或全部操作的实现延迟到子类中,因此,一个抽象类不能被实例化。在抽象类中定义却没有实现的操作成为抽象操作(abstract operation)。非抽象类称为具体类(concrete class)。子类能够重定义(override)父类定义的操作,重定义使得子类能接管父类对请求的处理操作,类继承允许你只需要简单的扩展其他类就可以定义新类,从而可以很容易地定义具有相近功能的对象族。

下面我们来看一个例子:

 

 

 

    如图我们建立了一个AddEmployeeTransaction的抽象类,在这个类中我们抽象除了员工类共同的属性:名称、ID号、地址,针对钟点工员工、薪水员工和提成员工三个具体类,他们有自己不同的属性比如钟点工员工有每小时报酬率,薪水员工有薪水,提成员工有提成率和薪水两个属性。

public abstract class AddEmployeeTransaction:Transaction

    {

        private readonly int empid;

        private readonly string name;

        private readonly string address;

        public AddEmployeeTransaction(int empid, string name, string address)

        {

            this.empid = empid;

            this.name = name;

            this.address = address;

        }

        protected abstract PaymentClassification MakeClassification();

        protected abstract PaymentSchedule MakeSchedule();

        public void Execute()

        {

            PaymentClassification pc = MakeClassification();

            PaymentSchedule ps = MakeSchedule();

            PaymentMethod pm = new HoldMethod();

            Employee e = new Employee(empid, name, address);

            e.Classification = pc;

            e.Schedule = ps;

            e.Method = pm;

            PayrollDatabase.AddEmployee(empid, e);

            

        }

    }  

像大多数美丽新世界一样,继承最终也被证明是不是万能的,到1995年,人们清楚地认识到继承非常容易被过度使用,而且过度使用的代价是非常高的,继承是一种非常强的关系,派生类不可避免的要和他们的基类绑定再一起。所以我们减少了对继承的使用,常常使用组合或者委托来代替它,所以我们选择了策略模式。

3.2.5基于策略模式的变迁

定义一系列的算法,把它们一个个封装起来,并且使它们可互相替换。本模式可以使得算法独立于使用它的具体类。

策略模式使用了一种非常不同的方法来倒置通用算法和具体实现之间的依赖关系,我们将通用的算法放入一个接口中,我们从接口中定义一系列的算法,把他们一个个封装起来,并且使它们可相互替换,本模式使得算法可独立于使用它的类对象而变化。一个以这种方法封装的算法称为一个策略

许多相关类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。

需要使用一个算法的不同变体,例如你可能会定义一些反映不同的空间时间权衡的算法。当这些变体实现为一个算法的类层次时,可以使用策略模式。策略模式消除了一些条件语句提供了用条件语句选择所需的行为以外的另一种选择,当不同的行为堆砌在一个类中,很难避免使用条件语句来选择合适的行为,将行为封装在一个个独立的strategy类中消除了这些条件语句。一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的策略类中以替代这些条件语句。

关键技术:委托(delegation)是一种组合方法,它使组合具有与继承同样的复用能力,在委托方式下,有两个对象参与处理一个请求,接收请求的对象将操作委托给它的代理者(delegate)。这类似于子类将请求交给它的父类处理,接收请求的对象将自己传给被委托者(代理人),使被委托的操作可以引用接受请求的对象。委托的主要优点在于它便于运行时刻组合对象操作以及改变这些操作的组合方式。一个替代继承的方法 易于切换、易于理解、易于扩展。

下面的例子中演示了一个表示统计一些产品总价功能的接口和接口委托的方法的具体实践。

 

通过引入IValueCalculate接口,先通过继承接口实现了FValueCalculator类,保证了ShoppingCartFValueCalculator之间没有直接的依赖性,在运行时刻才将FValueCalculator注入到ShoppingCart类中

public class Product

    {

        public int ProductID { getset; }

        public string Name { getset; }

        public string Description { getset; }

        public decimal Price { getset; }

        public string Category { getset; }

 

    }

 

    public interface IValueCalculator

    {

        decimal ValueProducts(params Product[] products);

    }

   public class FValueCalculator : IValueCalculator

    {

        public decimal ValueProducts(params Product[] products)

        {

            decimal sum=0;

            foreach (Product pd in products)

            {

                sum += pd.Price;

            

            }

            return sum;

        }

    }

public class ShoppingCart

    {

        private IValueCalculator calculator;

        public ShoppingCart(IValueCalculator calcParam)

        {

            calculator = calcParam;

        }

        public decimal CalculateStockValue()

        {

            Product[] products ={

                               new Product(){Name="足球鞋",Price=275M},

                               new Product(){Name="T",Price=75M},

                               new Product(){Name="足球",Price=85M},

                               new Product(){Name="羽毛球",Price=25M}

                               };

            decimal totalValue = calculator.ValueProducts(products);

            return totalValue;

            

        }

    }

为了验证我们的算法正确性我们针对FValueCalculator类编写了测试函数,验证该类的正确性:

       [TestMethod]

        public void TestFValueCalculator()

        {

            FValueCalculator fv = new FValueCalculator();

           ShoppingCart sc = new ShoppingCart(fv);//实例化ShoppingCart类时将计算的方法委托给FValueCalculator类。

            decimal  sum=sc.CalculateStockValue();

            Assert.AreEqual((decimal)460.00,sum );

            

        }

运行测试结果如下图顺利通过

 

这时使用这个统计系统的超市搞了一个打折活动要求在不影响ShoppingCart决策类的情况下使用一个新的IValueCalculate接口实现算法来对商品进行打折处理,我们新建下面LinqValueCalculator类:

public class LinqValueCalculator : IValueCalculator

    {

        private decimal discount;

        public LinqValueCalculator(decimal dis)

        {

            this.discount = dis;

        }

       

        public decimal ValueProducts(params Product[] products)

        {

            return products.Sum(p => p.Price)*discount;

        }

    }

 

 LinqCalculator编写单元测试验证:

[TestMethod]

        public void TestLinqValueCalculator()

        {

            LinqValueCalculator lv = new LinqValueCalculator((decimal)0.8);

            ShoppingCart sc = new ShoppingCart(lv);// 实例化ShoppingCart类时将计算的方法委托给LinqValueCalculator类。

            decimal sum = sc.CalculateStockValue();

            Assert.AreEqual((decimal)(460 * 0.8), sum);

 

        }

可以看出在系统运行时刻通过策略模式通过接口将具体算法委托给实现类,使算法独立于使用它的具体类。

3.2.6基于命令模式的变迁

将一个请求封装为一个对象,从而使你可用不同的请求对类进行参数实例化,对请求排队或记录请求日志,以及支持可取消的操作。

当用户决定增加一个新雇员时,该用户必须详细指明成功创建一条雇员记录所需要的所有信息。在使用这些信息前,系统需要对这些信息进行验证语法和语义上的正确性。Command模式可以协助完成这项工作。Command对象储存了还未验证的数据,实现了实施验证的方法,并且实现了最后执行事务操作的方法。这实现了实体上解耦和时间上解耦,这给我们带来的好处在于很好地解除了从用户获取数据的代码、验证并操作数据的代码以及业务对象本身之间的耦合关系。

 

 

 

例如,在图13.5中,AddEmployeeTransaction类包含有和Employee类相同的数据字段,同时它还持有一个指向PaymentClassification对象的指针。这些数据字段和对象是根据用户指示系统增加一个雇员时指定的信息创建出来的。

public interface Transaction

    {

        void Execute();

    }

public abstract class AddEmployeeTransaction:Transaction

    {

        private readonly int empid;

        private readonly string name;

        private readonly string address;

        public AddEmployeeTransaction(int empid, string name, string address)

        {

            this.empid = empid;

            this.name = name;

            this.address = address;

        }

        protected abstract PaymentClassification MakeClassification();

        protected abstract PaymentSchedule MakeSchedule();

        public void Execute()

        {

            PaymentClassification pc = MakeClassification();

            PaymentSchedule ps = MakeSchedule();

            PaymentMethod pm = new HoldMethod();

            Employee e = new Employee(empid, name, address);

            e.Classification = pc;

            e.Schedule = ps;

            e.Method = pm;

            PayrollDatabase.AddEmployee(empid, e);

            

        }

    }

public class AddSalariedEmployee:AddEmployeeTransaction

    {

        private readonly double salary;

        public AddSalariedEmployee(int id, string name, string address, double salary):base(id,name,address)

        {

            this.salary = salary;     

        }

        protected override PaymentClassification MakeClassification()

        {

            return new SalariedClassification(salary);

        }

        protected override PaymentSchedule MakeSchedule()

        {

            return new MonthlySchedule();

        }

    }

 

    3.3基于Petri网的敏捷开发过程模型

本文在以上Petri网相关理论的基础上结合敏捷软件过程的相关知识提出了一种基于Petri网的敏捷软件开发过程模型,如图3.6所示,并在第四节中对各个变迁进行了实践验证。

 

3.6敏捷软件过程网

    敏捷软件过程网是描述实际应用中的过程定义和过程演化的,它拥有PETRI网的有限性,安全性等属性。同时,实际过程中应保证过程设计的合理性。本文定义软件网库所中的托肯用来表示条件,只具有二值得布尔量,所以软件过程网是安全的,其次,该软件过程是可以适当结束的。网络系统中不包含死变迁。根据文献[7]的定义2.42.5可以证明敏捷软件过程网是完全合理的。

2016-11-03 17:37:57 buding_pmp 阅读数 4085
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

[摘要]  
敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的,此外还需要各个业务部门对敏捷的理解和支持,形成合力。以下分享产品项目里的九个敏捷开发实战经验。

  敏捷开发越来越火热,但在实际应用当中很多时候都是只有敏捷的“形”,却缺少敏捷的“神”,还只是在摸索中。
  在《Scrum:兼顾计划与灵活的敏捷开发》一文中,作者最后也提到过,借鉴一种新的模式的时候,最好能够批判性的吸收其精华的部分,不能全部照搬,照搬了反而会出问题。
  其实敏捷对产品经理的要求是很高的,需要安排至少两个迭代的任务,两个迭代的规划。
  对程序员的要求也很高,当所有的任务都拆散了之后,最终做出来的东西要形成一个产品,技术人员的整体意识要比较强,且一开始就得熟知产品的整个规划,否则到最后就会出现所有任务都已完结,合并出来的最终产物却是什么都不是。
  并且敏捷开发不仅仅是IT部门的事情,还需要各个业务部门对敏捷的理解和支持,形成合力,从而提升开发效率和业务满意度。
  运行一段时间的敏捷之后,发现最容易接受敏捷这种方式的是开发团队,不管是瀑布式还是敏捷,只是做工作的形式不一样了,进度更容易把握了,更能适应需求的变化了,实质其实并没有变化。
  对测试团队来讲,测试资源调配会更加的紧张,敏捷要求做完一条侧一条,与原先的整体项目排期完全不一样;对产品经理来说,敏捷能让自身更好的掌握整个产品的进度。
  但需求分析与产品设计阶段的敏捷拆分还是较为头疼的,究竟要不要写文档了,是不是有什么做什么,还是说要规划完整体设计之后才进行拆分?疑问很多,搜集了部分资料,结合敏捷实践的经验,分享如下:
  一、敏捷开发最少需要维护哪些文档?
  软件或者系统产品终归是人来维护的,业务知识和技能的传递就成为产品可持续发展的一个重要因素,这就需要有知识性的沉淀,需要有文档的产出。
  实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档,因此太多的文档只会消耗团队有限的时间,并不能带来多大的好处;敏捷开发照样重视文档的作用,也重视文档的维护。
  但文档宜少且精炼,一般情况下建议维护三份文档:
  《产品需求规格说明书》
  也即PRD:定义产品应该具有的功能、边界描述等,它作为产品团队之间共同的讨论基础,并在设计和开发过程中不断的更新维护,并记录所有的需求变更;
  《系统设计说明书》
  开发人员编写的技术设计,包含数据库E-R图,架构设计等:说明产品如何实现,内部之间是什么关系;
  《测试用例和测试报告》
  由测试人员编写:记录所有功能点的测试计划、过程和测试结果;
  二、敏捷开发是否需要系统设计?
  前面也提到过,敏捷开发对开发人员来讲实质差异不大,只是以小周期代替大周期。
  小周期包括:需求、设计、开发、测试、发布,这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间,与小周期是相对立的。
  因此敏捷开发不主张高度细化和完整的设计,提倡做出一个大粒度的框架性设计,一般指架构设计或者系统设计,避免在以后的重构中发生架构级别的变化,然后在逐步实现的过程中逐渐深入展开、细化。
  传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。
  三、敏捷开发是否需要项目计划?
  敏捷开发只是把整体拆分成许多个体,产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。
  它是一种有组织有目标的行为,往往我们都将其作为一个项目来管理,这就是讨论为什么有产品经理的同时还要有项目经理,为什么要求产品经理要有项目管理的能力,因此它需要项目计划。
  但这个计划是一个短程计划,根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;
  四、敏捷开发的迭代周期大概多长?
  敏捷开发的迭代周期没有硬性的规定,结合项目里程碑、目标、功能实现情况、产品稳定性综合决定,如果产品用户活跃、功能实现难度小、维护复杂度低,建议以周为周期。
产品项目里的九个敏捷开发实战经验
  对于规模比较大、维护复杂度高的产品,考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本,给用户心理上带来额外的负担:他会认为产品质量低,质量控制不严谨等;
  五、敏捷开发为何提倡小版本?小版本有哪些优势?
  小版本的目的就是分解复杂度、降低风险,改善团队士气等;小版本有众多优势:
  1、总体风险比较少:小版本变化小,总是在上一个版本基础上局部调整和增加,技术复杂度低;由于规划的功能较少,工作量也易于估算,所以其总体风险比较少,常常能如期发布;
  2、需求的接纳能力强:由于小版本快速实现并发布测试,然后就进入下一个版本的规划实现周期,这样新需求一旦提出就能快速进入开发视野,就能尽快实现;
  3、测试和开发高效协作:开发和测试可以并行工作,当开发实现第一个版本时,测试设计测试方案和用例;发布第一个版本后,开发就进入下一个版本轮次,测试就应用测试方案测试刚才发布的版本,提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug,然后发布新版本,如此循环往复,开发和测试实现高效协作;
  六、敏捷开发与重构的关系如何?
  敏捷开发以重构为基础,时时刻刻处于重构过程中;
  七、敏捷开发为何强调团队人员的参与、用户的参与?
  敏捷强调团队成员的高度参与就是要统一认识,把团队的目标变成每个人的工作目标,使之为每个团队成员的认同,形成高度的凝聚力,以达到群策群力、高效协作的效果。
  由于没有高度细化的文档,成员之间交换信息的唯一渠道就是面对面沟通,良好的团队氛围和协作关系促进这种沟通,并使消息有效传达。
产品项目里的九个敏捷开发实战经验
  用户由于缺乏专业训练,无法清晰、准确的表达其意图,导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中,我们常常可以听到这样的话:
  “是的,就是这样的”
  “这正是我想要的……”
  “这里需要修改一下……”
  “我的想法是这样的……”
  这个过程中,用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西,并最终让用户喜欢它,唯有用户喜欢它才能用好它,那么我们怎能不认真听取用户的意见呢?一句话总结就是:用户参与帮助我们做正确的事情!
  八、怎么才能评估团队是否已经敏捷了?
  由于敏捷开发没有标准的可供参考的实践过程,所以很难通过某个过程而断定其开发过程敏捷了,那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷,常见评估项目团队是否已经敏捷的方法如下:
  • 团队有共同的愿景,并且对这个愿景充满信心;
  • 团队有明确的阶段目标并且为每个成员所知晓;
  • 团队知晓当前计划:做什么、何时完成、预期效果等;
  • 团队任务是低耦合的,并且紧密协作;
  发布过程是轻松愉快的,构建版本并不断测试是常态行为之一。
  九、敏捷开发能缩短项目时间并提高质量吗?
  从我的实践经验来看是可以的,但目前无法提供量化的数据做参考,只能从几个方面评估和推断:
  • 用户的参与帮助团队把功能一次性完成并做正确,缩减了返工的时间;
  • 不断的重构和测试发布能把问题发现在早期,整体质量显著提高;
  • 过程目标导向,使团队高度集中于项目目标,提高了生产力;
  • 不断的发布对团队是种正向激励,荣誉感和成功欲使团队保持持续的激情;
  以上是一些敏捷开发过程当中的疑问,其实还有很多,目前我这边还只是主推让开发和测试团队敏捷,PD团队还在摸索当中。下次我会分享一下如何在需求这个层面用敏捷的方式来设计,去产出PRD文档。敏捷设计、敏捷开发、敏捷测试连在一起,这样才能最大限度的发挥敏捷的效用

2010-05-27 12:22:41 zhanghsh2010 阅读数 300
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
1 Story划分能够根据INVEST原则:独立的(Independent)、可商讨的(Negotiable)、有价值的(Valuable)、可以估计的(Estimatable)、足够小的(Small)、可测试的(Testable),支撑后续分迭代进行开发;
2 定义了不同用户类型的使用场景,是场景测试的输入;
3 定义明确的Story验收准则(具体要求),帮助理解规格,减少由于规格不清楚造成的返工和反复沟通;验收用例需要在Story开发前或开发中给出,不能滞后于开发,;
4 给出明确的Story间的依赖关系,从而确定开发顺序,减少打桩和需求反复;
5 明确如何演示;
2010-10-27 16:43:00 woshicolorwolf 阅读数 352
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师

    敏捷开发。至今不是真正的明白什么是敏捷开发,但是也经历了将近4个月的所谓敏捷开发过程了。
就先记录下自己的一些想法吧。
    刚听到这个敏捷开发的名词时感觉很玄乎的开发模式,网上大家都在讨论。可是实际到了项目中,却
没有那么神秘了。每天早上会有15分钟的晨会,先复述下昨天的工作内容,然后用最简练的话语描述今天
要做的事。具体的遇到的问题不会在晨会中进行讨论,避免时间的流失。鼓励问题产生方与问题的处理方
直接在会下沟通,这样可以有效的节省其余人员的时间。
     以上就是敏捷的开发每天的过程。敏捷的具体工作内容是什么呢?PM会建好feature,PG自己根据自己
情况去拿这些feature,然后给拿到的feature估计下完成时间很进度。这个估计的过程我感觉没有一定的开发
经验是很难准确的估计出来的。关键是feature的建立,这种逐步的开发模式可能的目的之一就是为了解耦,而
能不能解耦关键是要看这些feature的水平了。如果feature之间可以很好的解耦那么目的算是达到了。所以我个
人的感觉就是建feature才是敏捷开发的关键所在。怎么建feature,如何建feature。如果真的可以做到像搭积木
那样随意的加减feature的话,那样就最圆满了。可是究竟又有多少可以达到呢?

2008-08-27 17:26:12 iteye_6036 阅读数 82
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10404 人正在学习 去看看 CSDN讲师
二弟的一篇介绍 敏捷的文章,希望有机会在 GBS 的系统实施中能够早日用上 敏捷


关于敏捷
2008-08-27 10:02 | (分类:默认分类)
今天写实习总结,描述了一下这几个月的收获。截取其中的一段关于敏捷的感想。

Scrum对于我这样的开发人员来说,让我可以直接参与到整个开发周期的各个阶段。在评估会议时,团队中的每个成员都有权对产品的需求项进行评估,确定需求的工作量大小。在Sprint 计划会议1中,由Product owner对该Sprint中的需求项进行需求描述,明确具体的需求。在Sprint计划会议2中,Scrum master组织团队对既定产品backlog的需求项进行任务划分,将每个任务细化到每天的工作中,确保在Sprint周期中,每个人的任务分工明确。

在Sprint每日的例会中,每个开发人员报告自己的工作进度,并明确下一天的任务,遇到障碍,可以及时找到相应的人员开会解决。在Sprint的评审会议中,对Sprint的完成的任务进行提交演示,并可以增加新的需求项。在Sprint的回顾会议中,确定这个Sprint的成功和失败的经验,及时总结。

我们开发人员在整个Sprint周期中,可以明确需求,并自主地安排工作进度,在技术增长的同时,也增加自己的工程管理的经验,有利于个人职业生涯的发展。Scrum相比于其他的过程模型,更加注重团队个人素质的提高,并且能够快速的应对变化。

TDD也是一种敏捷开发的方法。它的主要思想是通过建立一套可执行的测试用例,保证代码的实现与具体的需求的一致性,以测试用例作为中介,建立一个有序的工作方式:从需求用例中导出测试用例,从测试用例中导出代码的接口和实现。

在我平时的开发过程中,严格的遵守了TDD的指导。拿到一个具体的Use case时,先测试几组测试数据,然后用JUnit建立一个Test case与Use case对应,在Test case中采用Mock对象,先虚拟地对测试方法进行实现,等测试通过之后,再抽取出具体的接口,然后实现。

我觉得TDD的好处是在产品的开发过程中建立了一套可运行的Test case,让需求变得具体,可控。一旦需求发生了变化,可以从Test case 入手,然后再修改实现代码。使需求的变更在代码的级别变得可控。

我还学习了基于Java平台的动态语言Groovy。这是一种敏捷的开发语言,比Java语言具有更高的抽象性,用少量的代码表现更多的功能。

在IBM的收获是让我体验到了“敏捷”无处不在。从敏捷软件过程的Scrum方法,到测试驱动的开发方式,到敏捷的开发语言,整个软件工程的各个方面都有敏捷的出现。我考虑过这个问题,为什么这两年敏捷变得如此的流行。我觉得一个原因是让需求的变更变得可控。软件工程发展了10多年,积累的大量的原始资源,各种平台,中间件林立。客户对软件的需求从最初的简单发展到如今的非常复杂,业务变更非常频繁。过去那种僵硬的,按步就搬的开发方式和管理方式已经不再适应变化。比如采用瀑布模型,开发了几个月客户才看到最终产品,但是最初的需求已经改变地面目全非了。Scrum的好处是它把“变”与“不变”控制地很好,在Sprint进行中Sprint backlog是不应发生改变地,保证了工作的有序。在Sprint的开始和结束之后可以进行需求的变更。由于Sprint的周期长度较短,这种短暂的稳定,可以让团队在正确的道路上持续的前进,而不是全程的变化,找不到正确的道路。

敏捷是软件工程的发展方向,让我们拥抱变化,让生活变得更美好一点。

http://www.itpub.net/868217.html

博文 来自: szjerrywangyong

敏捷项目管理模式

阅读数 2702

没有更多推荐了,返回首页