2018-08-10 11:26:13 fan2252228703 阅读数 278
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

第一个管理的项目采用的是敏捷开发,以下是个人对敏捷开发的一点实践总结。希望能给大家提供一些帮助。

(关于敏捷开发的3355,敏捷宣言,十二准则在最下边有。)

敏捷开发流程:

1.首先需求负责人理清需求。

2.团队内部要熟悉了解(可以做做游戏)。

3.当天下午及晚上迭代任务拆分。评估工时。

4.开始第一天每日例会领取任务。

5.迭代中旬测试用例评审,接口文档评审,故事验收标准。

6.期间每天早上的站会主要是总结昨天做了什么,遇到了什么问题,今天要干什么(承诺)。负责人需要对问题进行解决。不要阻塞开发。

7.迭代结束需要开迭代评审,迭代回顾。晚上进行任务拆分。

8.上一迭代未完成的任务放进下一迭代。需求变更的也放入下一迭代。

 

 

详细过程:

1.一周主要有以下几个过程:

每日立会。

迭代评审。

迭代回顾。

迭代计划会。

接口评审。

测试用例评审。

故事验收标准。

周报。

演讲分享。

 

每日立会:

每日立会是用来回顾自己在昨天做了什么,还有什么任务没有完成,为什么没有完成,遇到了什么问题需要解决。自己今天要做什么。根据反应的情况进行调整。负责人需要对所有的问题故障进行尽快的解决。

每日立会的公开性透明性能够清楚的认识到每个人的能力和问题。团队成员领取任务是一种承诺,既然承诺了就需要去完成。

 

迭代评审:

迭代评审是对本次迭代的评审,需要严格按照故事的验收标准来进行评审。是检验本次的迭代成果的时候。检验本次的完成情况并进行梳理,看有哪些没有完成,为什么没有完成,是否有什么风险,并将没有完成的移到下一迭代。完成后需要将本次迭代的成果交给甲方进行验收,看是否有需要改变的地方。如果有的话将需要改变的需求移到之后的迭代进行。

 

迭代回顾:

 

回顾本次迭代的团队情况。每个人需要写团队的三个评价:

好,不好,待改进。必须是针对团队的,不能针对个人。之后将统计结果写在黑板上,由团队人员进行投票。每个人必须对每个栏目进行投票,可以投多票反对,一票赞同,赞同票必须投,反对票可以不投。完成后总结团队的情况并解析。下次迭代改进。

 

迭代计划会:

迭代计划会需要对下次迭代的需求进行讲解和任务划分。将故事划分成一个个任务,由相应人员进行工时评估,录入系统。完成后将任务和故事打印出来,贴到看板上。

 

迭代本身:

这个暂时不知道是什么意思。

 

接口评审(迭代中旬):

对团队人员写的接口进行评审,看是否符合标准,解释是否明了,需要用到该接口的人员有什么问题都可以提出来。需要修改的则现场进行修改。

 

测试用例评审(迭代中旬):

对测试人员编写的测试用例进行评审,主要是测试人员进行评审看用例有那些缺陷或不严谨的地方。反思自己写的测试有什么不足。

开发人员则需要注意看看测试人员会测试那些东西,反思自己思维上有哪些没有考虑到,尽量的在开发阶段进行完善。不要提交到测试那一大堆bug。

 

故事验收标准:

故事的验收标准需要由团队人员来进行编写,提交给负责人,负责人同意后,则迭代评审时按照该标准进行评审。

周报:

每个人需要在一周结束时写一份周报来总结。周报内容应包括以下内容:

1.本周所做的工作

2.本周完成的工作

3.本周遗留的工作

4.有挑战性的工作

5.有成就感的工作

6.所学到的知识

7.自己需要改进的方面

8.建议团队需要改进的方面

9.其他

 

演讲分享:

这个是附加的,因为咱们都缺乏一些经验性,常识性的东西,所以需要以演讲的形式来为团队成员扩充知识面。

 

 

敏捷开发术语解析:

分组:开分前需要分好团队,根据不同情况将一个团队分成几个组,可以不分。并取个名。

迭代:一个项目可以分成多个迭代来进行完成。每个迭代完成一部分任务。以主线程为中心。以价值为核心。来判定优先级。

用户故事:将所有的需求划分成一个个用户故事,如果一个用户故事的任务量太大时必须拆分成几个小故事。用户故事有史诗级用户故事和普通用户故事。史诗级用户故事就是特别打的一个任务点。必须拆分成n多个任务故事。

用户故事举例:作为xxx,我要通过xxx,进行xxx。

用户故事地图:用户故事地图就是由许多许多的用户故事及任务张贴到物理看板上之后组成的一个地图。

任务:每个故事可以拆分成多个任务。由不同人员进行认领完成。

任务划分:每个用户故事可以拆分成很多任务,常规的有:前台页面开发,接口文档设计与开发,后台逻辑开发,测试用例编写,接口自动化测试,页面测试。  数据库设计一般在开发前就以完成,不过也可以在开发时添加数据库设计任务。

燃尽图:

所有的用户故事和任务被划分工时后会形成一个燃尽图,燃尽图以一个迭代为周期。随时间推移,团队人员需要为燃尽图进行工时的增减。燃尽图可以直观的看出团队任务的完成情况。

电子看板更新:

每日立会开完后,需要跟新电子看板,将自己认领的任务拖到相应位置。一天当中完成任务后需要将任务拖到完成状态,如果阻塞需要拖到阻塞状态。完成后可以继续认领新的任务。并将物理看板上认领相应的任务,当一天结束时,如果手头的任务没有完成则需要更新剩余工作量。

 

敏捷看板:

敏捷看板有物理看板和电子看板,物理看板只能每日立会的时候可以拖动,电子看板可以随时拖动,敏捷看板可以让团队人员更加直观的看到团队的完成成果和项目进度。

看板有以下几个字段:

用户故事,todo,doing,block,done.

 

 

工具:

敏捷开发的工具网上有很多,我们用的是自己的。

需要具备的功能:

敏捷看板 电子看板及燃尽图的展示。

用户需求 将一个模块拆分成多个用户需求

用户故事 将一个用户需求拆分成多个用户故事

迭代计划 迭代计划时长,迭代完成情况统计,团队人员完成情况统计等等。

缺陷管理 当测试人员测出bug后可以提出缺陷有开发人员进行修改。

用例管理 对测试用例进行管理。

模块管理  一个项目首先划分为一个个模块

 

持续集成:一键自动化集成部署。

 

自动化测试。测试人员进行自动化的接口及页面测试。

 

代码扫描。对所有代码进行,不合规范的将会报错。

接口管理:我们使用的是本地搭建的rap2。

敏捷宣言:

个体和互动 优于 流程和工具

工作的软件 优于 详尽的文档

客户合作 优于 合作谈判

响应变化 优于 遵循计划

 

SCRUM这个框架里面包含了这几个核心的要素:

1、3个角色:SM、PO、开发团队(自然包括了我们的开发人员和QA)。

2、3个产出物:Product Backlog、Sprint Backlog、交互的可用软件工件。

3、5个活动:计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。

4、5个价值观:公开、专注、勇气、承诺、尊重。(这五个价值观尤其重要,贯穿整个敏捷开发。)

十二条准则:

12原则作为敏捷开发对于软件开发流程的指导性纲领,其实是对敏捷宣言进行了具有实际操作意义的解释。下面是敏捷宣言12原则:

我们遵循以下准则:

1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。

4、项目过程中,业务人员与开发人员必须在一起工作。

5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

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

12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。

 

 

 

 

 

2016-08-29 15:22:41 myhead756 阅读数 5443
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

最适合App的开发模式——敏捷开发

 

传统的软件开发模式需要经历问题评估、计划解决方案、设计系统架构、开发代码、测试、部署和使用系统、维护解决方案等过程,如下图




采用传统软件开发模式的最大问题是开发周期过长,迭代速度慢。移动互联网行业发展速度快,需求不断变化,产品更新迭代的频率高,基于移动互联网的以上特点,就引入了Scrum这个敏捷开发框架。

 

Scrum简介:Scrum是一个敏捷开发框架,是一个增量的,迭代的开发过程。在这个框架中,整个开发周期包括若干个小的迭代周期,每个小的迭代周期成为一个Sprint,每个Sprint的周期建议为2~4周。在Scrum中,使用产品Backlog来管理产品或项目的需求,产品Backlog是一个按照商业价值排序的需求列表。在每个迭代过程中开发团队从产品Backlog挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint会议上的分析、讨论和估算得到一个Sprint的任务列表,称为Sprint Backlog

 

Scrum的流程如下图↓

 

Sprint 计划会议

Sprint计划会议前,产品经理所要实现的产品需求(产品Backlog)以用户故事(即从用户的角度去描述用户所需的功能)的形式确定下来,并画出原型图,UI根据原型图完成设计稿。产品经理同时确定各个产品需求的优先级。

Sprint计划会议期间(一般为2天),开发团队的成员不应该做任何开发工作,要将全部精力放在把产品需求分解成一个个开发任务,并估算开发时间。

估算开发时间需要注意以下几点。

1、对于所需要使用的新技术,要估算学习和调研的时间。

2、根据统计,每个程序员每天的有效工作时间是5个 小时左右,其他时间都被沟通、喝水、休息、上洗手间等琐事占据,如果某个任务估算超过5个小时,那就代表了这个任务完成需要超过一天的时间。

3、开发人员对于开发任务的估算尽可能精细,一般来说,每个任务的估算时间不应该超过5个小时,如果超过5个小时,就应该把这个任务再细分为多个更小的任务。只要尽可能精细地估算任务,总体估算时间是大概精确的,因为有的任务估算的时间比实际完成的多,有的比实际完成的少。

最后根据产品经理的优先级和开发人员的估算时间,确定这个迭代周期最终的开发任务和其对应的优先级,即完成Sprint Backlog

 

日常开发

 

App开发中,App通过APIApp后台交互,后台人员可以先设计好相关的API并让API返回假数据。

开发过程中遇到任何问题,必须及时找相关人员沟通。为了保证沟通的效果,可以采用下面的方法。

1、如果不是非常紧急的问题,可以等相关人员休息的时候再沟通。

2、解决一个问题,先梳理好情绪,沟通的时候对事不对人。

Scrum中有个关键的职位“Scrum master”,Scrum master一般有技术总监担任,团队和外部的沟通必须统一通过Scrum masterScrum master的最大作用是屏蔽外部对开发团队的影响,使开发的进度和开发的效率得到保证。

在开发的过程中需要注意:一个Sprint Backlog中,需求不能变更,UI确定后原则上只能做小修改。产品有新需求,下一个Sprint Backlog再考虑。

 

每日例会

 

每日例会前,团队成员应该整理各自的任务列表,包括:

1、昨天完成了哪些任务,每个任务使用了多少时间,没完成的任务估算还要多少时间。

2、剩余的开发时间

例会中产品经理和开发团队的成员都要参加,如果可以的话,让运营人员和市场人员也参与进来,这样可以使团队每个成员都对公司的产品有个整体的了解。

每个人在例会上报告一下3方面的事情。

1、昨天做了哪些工作?

2、今天准备做哪些工作?

3、有什么工作需要其他同事配合?

注意避免在会议上讨论问题,如果真的需要讨论,请在会议后和同事讨论,不要浪费整个团队的时间。

 

测试和修复BUG

 

产品开发完成就进入测试和修复BUG的阶段。

测试人员把测试得到的问题提交到BUG管理软件,每个BUG应该包含3个部分。

1、问题描述和重新步骤

2、测试人员

3、负责解决这个问题的人员,如果测试人员不知道具体负责人,把这个问题提交给技术总监,由技术总监指定解决问题的研发人员。

 

评审会议

 

在测试和修复BUG完成后全体人员开评审会议。相关开发人员在评审会议中向全体人员演示APP的功能。

 

回顾会议

 

研发完成后开回顾会议,每个成员都在会议中提两点。

1、这轮迭代过程中做得好的地方。

2、这轮迭代过程中做得不好的地方。

这个过程走两轮,即每个成员都要提两点做得好和不好的地方。注意当一个成员提出自己的意见时,其他成员不做任何的评论。

 

及时反馈

 

可以通过建立相关QQ群收集意见,在APP中可以增加一个意见反馈的功能。

 

总结

 

敏捷开发不是万能的,敏捷开发更适用于需求多变,开发周期端的项目。


2015-11-06 22:11:20 dc_726 阅读数 7347
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

BDD敏捷开发入门与实战


1.BDD的来由

2003年,Dan North首先提出了BDD的概念,并在随后开发出了JBehave框架。在Dan North博客上介绍BDD的文章中,说到了BDD的想法是从何而来。简略了解一下BDD的历史和背景,有助于我们更好地理解。

1.1 TDD的困惑

Dan在使用TDD敏捷实践时,时常会有很多同样的困惑萦绕脑海,这也是很多程序员敏捷实践都想知道的:

  • where to start
  • what to test
  • what not to test
  • how much to test in one go
  • what to call their tests
  • how to understand why a test fails

1.2 同事的小框架

当Dan用上了一位同事编写的小框架agiledox时,灵感闪现!这个框架其实很简单,它基于JUnit测试框架,根据测试类名和方法名,将每个测试方法都打印为类似文档的输出。程序员们意识到这个小玩具可以帮它们做一些文档性的工作,于是就开始用商业领域语法命名他们的类和方法,让agiledox产生的输出能直接被商业客户、分析师、测试人员都看懂!

// CustomerLookup
// - finds customer by id
// - fails for duplicate customers
// - ...
public class CustomerLookupTest extends TestCase {
    testFindsCustomerById() {
        ...
    }
    testFailsForDuplicateCustomers() {
        ...
    }
    ...
}

1.3 “Ubiquitous Language”

此时,恰逢Eric Evans发表了畅销书DDD(领域驱动设计),其中描述了为系统建模时,使用一种基于商业领域模型的Ubiquitous Language,让业务词汇渗透到代码中。于是,Dan决定定义一种分析师、测试人员、开发者、业务人员、用户都能懂的”Ubiquitous Language”

Feature: <description>
    As a <role>
    I want <feature>
    So that <business value>

Scenario: <description>
    Given <some initial context>,
    When <an event occurs>,
    Then <ensure some outcomes>.

就这样,BDD的雏形就出现了!但这种类似BRD的文档是如何与我们程序员的代码结合到一起的呢?下一节我们就详细分析一下。


2.三个核心概念

Feature、Scenario、Steps是BDD的三个核心概念,体现了BDD的三个重要价值:

  • Living Document
  • Executable Specification by Example(SbE)
  • Automated Tests

2.1 Feature

Feature就像是文档一样,描述了功能特性、角色、以及 最重要的商业价值

2.2 Scenario

场景就是上面提到的规范Specification。Cucumber提供了Scenario、Scenario Outline两种形式。使用时要注意,在Cucumber官博上的一篇文章“Are you doing BDD? Or are you just using Cucumber?”给出了一个反模式。

Scenario Outline: Detect agent type based on contract number (single contract found)
  Given I am on the "Find me" page
  And I have entered a contract number
  When I click the "Continue" button
  And a contract number match is found
  And the agent type is <DistributorType>
  Then the contract number field will become uneditable
  And the "Back" button will be displayed
  And the following <text> and <input field type> will be displayed

  Examples:
    | DistributorType | input field type | text                            |
    | Broker          | Date of birth    | Please enter your last name     |
    | TiedAgent       | Last name        | Please enter your date of birth |

看出来了差别吧:Scenario Outline的核心依然应该是商业规则,而不能因为它对输入和输出的细化就将重点转移到UI界面

Scenario: Customer has a broker policy so DOB is requested
  Given I have a "Broker" policy
  When I submit my policy number
  Then I should be asked for my date of birth

Scenario: Customer has a tied agent policy so last name is requested
  Given I have a "TiedAgent" policy
  When I submit my policy number
  Then I should be asked for my last name

2.3 Steps

Steps就是实际编码了,我们要在Java中实现出Feature文件中各种场景对应的代码,让它变成“活文档”!


3.实战(上):分布式集群构建

之所以选择这么一个例子来实战,是因为网上的大部分例子都很简单而且雷同。通过这个例子,也是想试验一下BDD对于“业务性”不强的而且还是分布式的系统(即基础设施或中间件)是否也能发挥作用。这次实战也是一次比较奇妙的经历,不少核心类、接口和关于系统设计的想法都在这个过程中自然涌现~

3.1 开发环境

IDE当然还是选择Intellij,并且开启Cucumber插件,因为本实例是基于Cucumber实现的(其实其他的框架如JBehave都非常类似)。然后新建Maven工程,引入以下依赖包:

    <dependencies>
        <dependency>
            <groupId>info.cukes</groupId>
            <artifactId>cucumber-java</artifactId>
            <version>1.2.4</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>info.cukes</groupId>
            <artifactId>cucumber-junit</artifactId>
            <version>1.2.4</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

3.2 编写feature文件

Feature相对比较好写,简单描述一下功能特性就行了。比如下面的集群自动创建功能:为了自动创建集群(功能),作为用户(角色),我想结点能自动互相发现形成集群以节省手工的工作量和时间(商业价值)。

Feature: Auto Cluster Creation
  In order to create a cluster automatically
  As a user
  I want the nodes can discover each other on their own

我们还需要一个启动类:

@RunWith(Cucumber.class)
@CucumberOptions(plugin={"pretty"}, features="src/test/resources", tags = {})
public class NodeDiscoveryStory {
}

3.3 选择典型场景

为了简化,我只选了一个最简单的两结点集群建立的场景。首先结点1形成集群A,当结点2加入集群A后,集群中应有两个结点1和2。

Scenario: create a cluster
  Given node-1 in cluster-A starts
  When a new node-2 in cluster-A starts
  Then cluster-A should have node: 1,2

场景的选择和编写至关重要,本例的实践过程中就碰到了一些问题,下面做一点个人的经验总结:

  • Given和When不要混淆:一个是环境上下文,一个是触发条件,例如”a cluster is running”和”a new node starts”。弄混的结果就是在场景1里的Given在2里又原封不动的变成When了。
  • 场景是可验证的不能含糊:这一点上与Feature不一样。一开始我描述的场景就比较模糊不清,例如”Then the cluster can acknowledge the new node”,这种描述不够精确,不好验证对错。实际上仔细想想,BDD对应设计的高层次与行为结果的可验证是不矛盾的
  • 只选几个典型场景:在BDD中千万不要追求覆盖率和细粒度,否则就将丧失BDD对业务逻辑的表现力!在Feature文件里只描述最核心的东西,把覆盖率这种只有我们程序员和QA关心的东西隐藏起来,在更细粒度的Case中去完成。

此外,还有关于Given和When是否要细分出一些And条件,比如本例中的Given和When就都可以分别拆成createNode和createOrJoinCluster两步,但这样的话会导致成员变量增多而显得比较乱,因为Cucumber中的Given和And、When和And之间是不能携带过去对象的。所以从下一部分的编码实现中能看出,最终我还是没有拆的那么细。

3.4 Steps编码实现

编码实现是最痛苦也最有收获的!一开始时一无所有的茫然,不断重构最终终于找到比较合理的设计。注意:代码不要跟着场景的描述走,比如变量cluster起名为clusterA,那就限定死了!我们的Steps应该是通用的,这里的Given、When都是可能用于其他场景的。

首先在@Given中启动一个Cluster加入一个Node,之后在@When中模拟在另一台机器上启动一个Node加入到集群的过程。因为实际上这个过程是在远程完成的,所以不能直接使用成员变量cluster。最后验证cluster中的结点列表,看是否已经包含两个结点。

public class MyStepdefs {

    private Cluster cluster;

    @Given("^node-(\\w+) in cluster-(\\w+) starts$")
    public void runCluster(String nodeId, String clusterName) {
        Node node = new Node(nodeId);
        cluster = new Cluster(clusterName, new CoordinatorMock());
        node.join(cluster);
    }

    @When("^a new node-(\\w+) in cluster-(\\w+) starts$")
    public void startNewNodeToJoinCluster(String nodeId, String clusterName) {
        Node newNode = new Node(nodeId);
        Cluster clusterSlave = new Cluster(clusterName, new CoordinatorMock());
        newNode.join(clusterSlave);
    }

    @Then("^cluster-(\\w+) should have node: (.+)$")
    public void joinCluster(String clusterName, List<String> nodeIds) {
        Assert.assertEquals(clusterName, cluster.getName());

        List<String> actualNodeIds = new ArrayList<String>();
        for (Node node : cluster.getNodes()) {
            actualNodeIds.add(node.getId());
        }
        Collections.sort(actualNodeIds);
        Assert.assertEquals(nodeIds, actualNodeIds);
    }

}

对比下面典型的单元测试代码能够看出,BDD的Steps代码因为对应着Scenario,所以步骤分的比较清楚。而在普通Test Case中,Case中就会堆砌着类似@Given、@When、@Then的代码,并且每个Case都会有类似的代码。所以一般我们会提取出一些公关的代码,以使Case更为清晰,但BDD则直接更进一步。

    @Test
    public void testCachePut2_List() throws Exception {
        CacheResult<Object> ret = redis.cachePut(CACHE_NAME,
                Arrays.asList(
                        new Person(1, 49, "alan"),
                        new Person(2, 34, "hank"),
                        new Person(3, 38, "carter")
                )
        );
        Assert.assertTrue(ret.isOK());

        List persons = redis.cacheGetAll(CACHE_NAME, Arrays.asList(1, 3)).getValue();
        Collections.sort(persons);

        Assert.assertNotNull(persons);
        Assert.assertEquals(2, persons.size());

        ...
    }

4.实战(下):核心类进化

下面就说一下通过这次BDD历险得到的核心类,以及是如何思考出来的。这个重构、思考、最终浮现出来的过程其实是最重要的!

最先映入脑海的就是Cluster和Node,其实Node也可以暂时用一个ID代替,之后有需要时再抽象成类,这里有些“着急”了直接新建了个Node类。

public class Cluster {

    private final String name;

    private List<Node> nodes = new ArrayList<Node>();

    public Cluster(String name) {
        this.name = name;
    }

    public void addNode(Node node) {
    }

    public String getName() {
        return name;
    }

    public List<Node> getNodes() {
        return nodes;
    }
}

public class Node {

    private String nodeId;

    public Node(String nodeId) {
        this.nodeId = nodeId;
    }

    public void join(Cluster cluster) {
        cluster.addNode(this);
    }

    public String getId() {
        return nodeId;
    }
}

写好了@Given、@When、@Then之后,就可以跑起来Cucumber试试了,肯定是报错的。现在自然就有疑问了,@Then中的断言如何能够成功呢?所以Cluster背后需要一个能够帮助分布式通信的组件,于是就加上Coordinator接口。同时,我们创建一个Mock实现,利用static静态变量模拟网络通信的过程。

public interface Coordinator {

    void register(Cluster cluster);

    boolean addNode(Node node);

}

public class CoordinatorMock implements Coordinator {

    /** Simulate network communication */
    private static List<Cluster> clusters = new ArrayList<Cluster>();

    @Override
    public void register(Cluster cluster) {
        clusters.add(cluster);
    }

    @Override
    public boolean addNode(Node node) {
        for (Cluster cluster : clusters) {
            cluster.handleAddNode(node);
        }
        return true;
    }
}

最后让Cluster注册到Coordinator上,调用addNode()接口模拟分布式通信,并添加handleAddNode()处理请求就可以了!这样我们就完成了BDD的一个简单实例!

public class Cluster {

    private final String name;

    private final Coordinator coordinator;

    private List<Node> nodes = new ArrayList<Node>();

    public Cluster(String name, Coordinator coordinator) {
        this.name = name;
        this.coordinator = coordinator;

        coordinator.register(this);
    }

    public void addNode(Node node) {
        coordinator.addNode(node);
    }

    public void handleAddNode(Node node) {
        nodes.add(node);
    }

    public String getName() {
        return name;
    }

    public List<Node> getNodes() {
        return nodes;
    }
}

5.总结

每种新事物的产生都不可避免地会伴随着各种各样的解读,毕竟每个人都有自己的看法和理解。有的理解深刻直达本质,有的独辟蹊径另立门派,也有的是偏见和误解。BDD也一样,可能会人被当做跟TDD一样的东西,也可能会被看做测试的一种。

通过本文的介绍,大家应该能看到BDD的闪光点。它提升了TDD的粒度和抽象层次,并以统一而规范的语言作为文档,消除了软件开发中各种人员的沟通障碍。同时以实用的框架将文档与代码粘合到一起,使文档可执行化、代码文档化。

2011-10-26 10:41:40 VipWangJian 阅读数 12
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波
(二)办公环境准备
安排一体化团队成员围坐在一起工作,目的是便于大家的沟通和交流;如果办公环境不能满足,也需要让一体化团队成员尽可能的靠近,尤其不要出现开发和测试不在同一楼层的情况。合理布置项目状态墙和开晨会的位置。

(三)现状评估、计划制定

项目启动时建议项目PL和敏捷教练一起对一体化团队的状况做一评估,包括:团队成员对敏捷的理解程度、技能、项目周期、规模、复杂度、准备采用哪些敏捷实践等。根据评估的结果,输出一个较粗的E2E迭代计划(迭代前准备阶段后期,和每次迭代结束后,都可细化或调整该计划)。同时要对迭代前准备阶段的活动有一个详细计划,包括:对评估发现的问题尽早采取一些措施(例如培训)、Story分析、配置库和持续集成环境准备等。

(四)项目启动会议
所有团队成员参加,类似于项目开工会,团队成员介绍、项目背景介绍、项目目标、大致的计划时间点,以及迭代前准备阶段的安排和任务分工等。

(五)建立持续集成环境
项目PL指定项目组的CI-CO人员,协调CMO创建项目文件夹,并初始化配置库;CI-CO要负责搭建持续集成环境。持续集成是最有价值的优秀实践,是敏捷开发的基础,要求持续集成环境必须在迭代开始前准备好,工具推荐使用ICP-CI。
2018-12-19 17:44:19 weixin_42556618 阅读数 101
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

​​

关注嘉为科技,获取运维新知

 

一、为什么不用“人天”?

传统的IT项目,尤其是软件开发项目,往往使用“人天”来作为工作量评估的量词、甚至是代表一种评估方式。在软件项目开发经典著作《人月神话》中,明确的指出了按“人月”或“人天”来评估需求工作量的巨大弊端,主因之一就是在于这个词让人产生了“可以使用更多的开发人员就可以更快速的完成软件开发”这一错觉。在Agile敏捷项目当中,大都避免在快速需求评估阶段使用“人天”。具体请参看《人月神话》。

                 

 《人月神话》中最著名的插图“焦油坑”

                           《人月神话》中最著名的插图“焦油坑”

 

二、Story Point故事点

智能边缘计算作为一种新模式,使得物联网的每个边缘设备都具备数据采集、分析计算,通信,以及最重要的本地或就近的“智能”。新的智能边缘计算同时利用了云计算的能力,利用云来大规模的进行安全配置、部署和管理边缘设备,并能够根据设备类型和场景分配智能的能力,从而让智能在云和边缘之间流动,获得两全其美的结果。

 

计划扑克基于Story Point故事点,扑克牌牌面上印刷的巨大数字就是故事点。

那么,什么是故事点呢?

“故事点”是Scrum敏捷开发过程中所使用的概念,它代表某开发团队内部所推选的一个抽象的标准工作量。一个故事点,可以是大家熟悉的一件较独立、较简单工作的全部内容,比如,一个常见功能页面所涉及的所有的开发工作,包括该页面UI的设计、代码的编写、数据库表的设计等等。

 

这样一来,在快速评估的过程中,一个新需求大概的工作量是上述这个“标准工作量”的2倍的话,那这个新需求的粗略工作量就是2个故事点。

 

一副计划扑克提供了一组不连续的故事点数字,以便于代表不同大小需求的工作量。

计划扑克的故事点数序列,一套13张,同一种颜色

 

三、牌面数字的含义

0表示所选需求块非常简单,或者可以通过重用快速搞定,不需要精力就能完成;

?表示根据目前掌握的情况,暂时无法评估该需求块需要多少故事点,需要进一步了解与细化需求;

咖啡杯用于提示团队成员该休息了,实在太累了。

 

与纸币的规则类似,牌面没有的点数可以由多张牌累加而成

 

四、牌面最大数字才100,不够用怎么办?

任何一个大需求,都需要渐进明细、直到足够小足够详细才能进行设计编码。因此,对于开发人员进行设计而言,超级大的或很粗粒度需求是没有太大意义的。对于不少团队而言,仅一个大小为100故事点的需求,就可能需要消耗好几个迭代周期的工作量,更不用说大于100的了。

 

使出100牌的开发人员,往往是希望表达对于业务的庞大复杂的不解或者恐惧、或技术投入或风险的担心。而对于自己感觉更加不靠谱的,可以直接出那张问号卡牌。

对于像大部分人都会评估为40或100牌面的大需求,需要由Product Owner负责或牵头来不断细化,直至拆分为多个且足够详细、足够小的子需求,才有可能进入下一个迭代周期的开发排期。

可灵活组合的牌面

 

 

五、注意事项

每副扑克都会包含1~2张使用说明,中文或英文,介绍扑克的基本使用规则。

 

每位开发人员,应拿到一套13张,以便使用纸牌表达自己对某需求块工作量大小的快速评估。有些型号的计划扑克,会有四套,每套一种不同的颜色。参与评估的开发人员多,就需要同时使用多副扑克。

 

针对Product Owner每讲解的一个新需求,所有开发人员都需要同时出牌,以便能表达出每个人的独立观点。

 

点数最集中的评估结论往往会被采纳。与大多数差异很大的评估者可能会被提问说出自己评估的依据。对于该需求最了解的人员的评估,往往会被高度重视,而不是一味的少数服从多数。

 

六、小结

Planning Poker计划扑克是很多敏捷开发团队非常喜爱的小工具,几元十几元一副的超低成本,在需求的快速评估阶段,可以让每个团队都全情参与进来、并且“无废话”的独立表达自己的观点,若运用得当,则可能大幅提高早期工作量评估及需求排期的效率。每个团队还可以进行微调、探索最适合自身及项目特点的玩法。在这一阶段评估成功完成之后,需求仍然较粗,还需要进行进一步的需求细化和具体开发工作的拆分与认领。

 

【注:】本文部分图文内容来自相关公司及互联网,该部分的版权属于原所有者。

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