2016-07-08 14:07:25 langzai2012 阅读数 4282
  • SCRUM敏捷开发视频教程

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

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

敏捷开发模式下需求分析岗 BA

传统的瀑布开发模式下需求分析岗是必不可少的。那么敏捷项目没有需求分析吗?在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了敏捷方法

思考:敏捷开发过程是否存在完整需求分析? 敏捷过程到底是如何做需求分析?   用户故事和用例有什么区别?  敏捷过程如何去管理需求的?

这些是一些想要实践敏捷的人一直在困惑的事情。 我们常常看到书中讲,程序员拿到一个用户故事后,怎么计划,怎么分解,怎么写单元测试,怎么小步前进,怎么持续集成。这是典型的程序员视角。事实上,敏捷方法分为三部分,敏捷项目管理,敏捷需求分析,敏捷软件开发。上述书中提到的完全是敏捷开发中的实践,很多人了解到的敏捷,只是敏捷的三分之一。

敏捷项目中谁来做需求分析?

在敏捷的团队中,作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看,只需要选择一张他感兴趣的故事卡片,了解清楚该卡片的需求,开始从功能测试写代码,等通过了所有测试就完工。基本上不需要考虑太多的事情,非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。 了解敏捷过程的人都知道,Kent Beck在XP过程中提到了现场客户,如果一个敏捷团队能够有现场客户,这当然是最棒的事情。但多数情况下,客户都是很忙碌的,很难全力投入到软件开发过程中。这时候,我们就需要商务分析师这个角色,来充当客户的角色。商务分析师最重要的职责就是与客户交谈,了解和分析需求,将其制作成用户故事并将需求转述给程序员。同时,商务分析师也要代替客户负责功能验收测试

敏捷项目中如何进行需求分析?

       敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流,搞清楚客户到底需要什么,到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向,就可以不迷失方向。和客户进行交流,最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验,客户说,我要这个功能,我想要怎么怎么样。这时候要特别注意,他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么,挖掘出他真正的目标。

       在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更? 搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。 举一个最常见的用户故事例子,“作为一个普通用户,我希望能够用用户名和密码登录,以便我能享受到个性化的服务”。其中,用户是系统涉众,登录是他想要做的事情,而他的目标是获得个性化的服务。 从这个例子我们可以想象到,这个页面可能存在两个文本框,用于输入用户名和密码,有一个按钮来登录,并且不登录就不能看到个人资料,另外,如果用户输入错误需要提示“登录失败请重试”。这就是可见性,也可以称为可测试性。我们可以根据这样的可见性写出功能测试,从而驱动这个用户故事的开发,这被称为 Acceptance Driven Development。

 

用户故事和用例有什么区别?

        用户故事的作用有两个,一个是作为进度跟踪的依据,一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求,因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成,这是敏捷需求分析的精华所在。 不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能,而不是文档。而用例需要详细的描述其操作步骤,以及每个异常路径,因而起到了文档的作用。用户故事是可见的商业价值,而不是功能描述。每个用户故事的粒度和工作量都相差不多,这和用例有很大的区别。用户故事是小粒度的,可测试的,可见的,并且是有价值的。 如下

 

【敏捷项目需求分析案例】 公司有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目,在开工的时候客户对功能需求还不明确,但需要快速推出抢占市场,正是最适合敏捷过程的项目。 在项目伊始,商务分析师和客户做了深入的谈话,了解他的商业构想,他的盈利模式,搞清楚宏观的结构,然后思考并整理获得的结果,花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善,不足以做好整个系统。但对于我们开始项目的前一阵,已经足够了。我们可以从这里开始项目。敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前,由一组有经验的开发人员大致评估一下用户故事,标记出不同的难度和风险,并提出问题供商务分析师来获得更详细的信息,商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选,客户可以选择这些用户故事,或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。 项目经理圈子客户看到每个迭代交付的可运行的软件后或者得到用户反馈后,常常会有新的想法冒出来。有些想法是好的,有些想法就属于看到别家网站有这个功能,不假思索的提出的功能。这些不同的需求都需要经过认真的分析,找出哪些是值得我们立即考虑的,哪些是不用急迫的去实现的。 有一次和客户谈话时,他说到希望增加拍卖功能。那么,我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑,我们发现网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求,因此,用户最终放弃了这个特性。 另一次,客服人员提出增加一个查询用户交易的功能,而此时我们有其他更加重要的功能需要先去考虑,查询用户交易功能可以由技术人员临时通过数据库直接代为查询,因为项目运营初期交易不是很多,暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上,始终没有排到最高的优先级。 客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合,客户也逐渐适应了许多敏捷思想,甚至我在和客户讨论时,偶然提起了后期的某种可能的情况,他们还能够帮我纠正应当考虑目前的情况,为近期的情况作计划。

 

敏捷过程如何去管理需求的?

        用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展,是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后,团队的开发速度基本保持恒定,我们就可以很容易的知道每个迭代能做多少个用户故事,这样就可以安排下一迭代的开发。

          每个迭代内分析好恰好足够下一个迭代开发的需求,就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成,包括需求的了解,分析,评估和排列优先级。 在每个迭代开始的时候,由商务分析师主持召开迭代计划会议,在会议上向所有的程序员解释这个迭代要完成的用户故事,然后由程序员自由提问,知道他们能够获得足够开始实现该功能的信息。 在程序员完成一个用户故事后,商务分析师还要来代表客户做功能验收测试,查看是否完成了预计的功能,是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然,更多的测试还需要QA来完成。

          项目实践中实践充分表明了,敏捷过程并不是没有需求分析,而是把需求分析过程分散到整个开发的过程中,让开发和需求分析并行进行。这就是公司敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中,起到了纽带和桥梁的作用,是一个团队不可缺少的角色 。

2009-07-22 13:26:00 killor2000 阅读数 4
  • SCRUM敏捷开发视频教程

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

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

2009-7-22

开始研究

 

(本文发表于程序员杂志2006年第4期)
     在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的勾当。不写文档,不作需求分析,没有项目经理,做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了敏捷方法。

     真的是这样吗?敏捷过程到底是如何做需求分析?用户故事和用例有什么区别?敏捷过程如何去管理需求的?这些是一些想要实践敏捷的人一直在困惑的事情。

 

     我们常常看到书中讲,程序员拿到一个用户故事后,怎么计划,怎么分解,怎么写单元测试,怎么小步前进,怎么持续集成。这是典型的程序员视角。事实上,敏捷方法分为三部分,敏捷项目管理,敏捷需求分析,敏捷软件开发。上述书中提到的完全是敏捷开发中的实践,很多人了解到的敏捷,只是敏捷的三分之一。

 

    在敏捷的团队中,作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看,只需要选择一张他感兴趣的故事卡片,了解清楚该卡片的需求,开始从功能测试写代码,等通过了所有测试就完工。基本上不需要考虑太多的事情,非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。

 

    了解敏捷过程的人都知道,Kent Beck在XP过程中提到了现场客户,如果一个敏捷团队能够有现场客户,这当然是最棒的事情。但多数情况下,客户都是很忙碌的,很难全力投入到软件开发过程中。这时候,我们就需要商务分析师这个角色,来充当客户的角色。

      我在ThoughtWorks的团队中担任的就是商务分析师这个角色。商务分析师最重要的职责就是与客户交谈,了解和分析需求,将其制作成用户故事并将需求转述给程序员。同时,商务分析师也要代替客户负责功能验收测试。

      敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流,搞清楚客户到底需要什么,到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向,就可以不迷失方向。和客户进行交流,最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验,客户说,我要这个功能,我想要怎么怎么样。这时候要特别注意,他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么,挖掘出他真正的目标。

   在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更? 搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。

 

     用户故事的作用有两个,一个是作为进度跟踪的依据,一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求,因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成,这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费,敏捷过程提倡足够就好,避免浪费。

     不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘功能,而不是文档。而用例需要详细的描述其操作步骤,以及每个异常路径,因而起到了文档的作用。用户故事是可见的商业价值,而不是功能描述。每个用户故事的粒度和工作量都相差不多,这和用例有很大的区别。用户故事是小粒度的,可测试的,可见的,并且是有价值的

  我们的实践充分表明了,敏捷过程并不是没有需求分析,而是把需求分析过程分散到整个开发的过程中,让开发和需求分析并行进行。这就是ThoughtWorks敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中,起到了纽带和桥梁的作用,是一个团队不可缺少的角色。 

 

 

  

2009-02-18 23:06:00 jarvisj 阅读数 2337
  • SCRUM敏捷开发视频教程

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

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

 

    《程序员》20092月刊,第70页有一篇如题的文章,比较清晰的阐明了敏捷与传统方法在分析时机、划分单位、细化过程、文档要求和应对变更五个方面的差异。摘抄要点如下:

     

     

    传统需求分析

    敏捷需求分析

    需求分析时机

    更多地集中在项目早期

    近乎均匀地贯穿于项目的整个生命周期

    需求划分单位

    基于功能分解,划分模块或子系统,一个模块或子系统的颗粒度通常较大

    基于能否独立业务价值,切割成一个个用户故事,一个故事有时会跨越传统的模块或子系统边界;故事的颗粒度较小

    需求细化过程

    一步到位,可供开发人员设计开发

    逐步细化,仅就下一个迭代需要实现的部分进行详细分析

    需求文档要求

    正式文档,往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约,也作为向客户提交的必备产出物之一。难维护,难验证(跟踪)

    非正式文档。仅仅是辅助开发团队与客户沟通,不作为规约,也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求

    应对需求变更

    有严格的控制流程,视变更为风险

    视变更为必然或预期中的事情

     

    敏捷方法中需求文档的作用和传统方法不同:

  1. 需求文档不是需要严格评审的项目产出物
  2. 不用担心需求文档过时或已经与系统不符
  3. 文档没有固定的格式,视沟通的需要而定
  4. 鼓励非文档方式的沟通
  5.  

    选择敏捷或传统过程与方法的考虑因素

    需求易变

    需求稳定

    客户或业务人员随时可找到并与之沟通

    客户或业务人员较难接触到

    客户更在意产品投入市场或系统投入运营所需的时间

    客户更在意产品或系统是否覆盖了制定的需求或功能范围

    团队(包括交付团队和客户团队)成员分布在同一地域

    团队成员分布在不同地域

    交付团队拥有更多的开发过程自动化技能及工作环境,诸如自动化测试、持续集成等

    交付团队拥有较少的开发过程自动化技能及工作环境

     

     

2016-07-24 21:26:34 djf847519018 阅读数 205
  • SCRUM敏捷开发视频教程

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

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

就目前我所待过的两个项目组,包括我了解到其他一些项目组的情况,基本都遵循了瀑布模式的实施方式,简单来说就是需求分析--设计--开发--测试--投产。

从入场开始需求调研到交付详细需求文档,我们称之为需求分析阶段。这个阶段基本都是需求人员入场,而开发团队并不参与,这就使得需求与开发团队是异步的。而需求人员在现场想要提供一份无偏差的高质量文档几乎是不可能的,这就造成了开发人员入场之后,包括开发之后才会发现的一些需求上的不合理,不明确,没有条件实现等等诸多问题。

而且即使需求写的比较细,开发人员在开发过程中依然需要不断的需要与需求人员沟通,而这些沟通中又有相当一部分是无效沟通。再加上并不是每个开发都很善于沟通,还会让一些问题进入测试阶段才能暴露,从而影响项目进度。

但是我们反过来想一下,为什么需求必须是讨论出来,而不能是通过一个详细设计文档去传达,使得每个成员都对需求来负责,而不是仅仅被动的接受。

对此,项目可以要求各团队的 PO,不再写详细的需求文档,而是出需求列表。强制要求,需求的传递必须通过需求澄清方式完成。

也就是需求、开发、测试人员,同时参与需求的分析工作。步骤如下:

  1. 需求人员列出项目组所有的业务场景,并进行排序;
  2. 开发、测试人员,听 PO 对每个场景进行讲解,注意 PO 不再提供详细需求的文档了,然后开发、测试人员可以要求 PO 对每个需求讲解清楚,直到听懂理解并能开始进行设计工作为止;
  3. 开发人员将 PO 讲解的需求给记录描述出来,需要包括基本的业务流程图以及接口说明,同时要求测试人员将需求的验收条件给写出来,整合成针对每个场景的需求澄清文档;
  4. 由 PO 确认需求澄清文档内容的准确性,如果无误可以开始进入开发过程了。

通过这样的方式,可以节省 PO 详细需求文档的时间,同时将需求的责任分担到每个角色的身上。因为,即使再详细的文档,研发和测试人员 还是需要阅读消化同时也需要多次找 PO 确认。直接通过讲解确认,我们也称为"需求的三次握手"过程,开发、测试、需求人员,实际完成了对需求的传递、需求验证规则的统一。


2017-04-11 20:28:11 huver2007 阅读数 1962
  • SCRUM敏捷开发视频教程

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

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


需求管理和实例化需求

软件开发的最大问题之一往往是需求,而且它也很容易的被作为替罪羊。在公司项目延迟和出大问题的最大借口,就是“需求不清楚、需求变更”。那把需求早点弄清楚不就行了嘛?听着挺容易,但要做好它却很困难。

敏捷迭代起来以后是否会好点呢?理论上会好点,因为需求在一个迭代中东西会少点,更容易理清楚。但就是因为一个迭代的周期短,在开完计划会议后,团队会更愿意直接投入到代码开发中去,他们认为需求已经可以了;项目经理也觉得讨论需求会浪费点时间,很多人包括开发者都认为写代码才是干活。

这样的话,实际上往往到迭代后面几天测试的时候才发现:测试人员、开发人员、产品负责人想的都不是很一样,但时间不够了,要不取消BUG,要不就是挪到下个迭代。这就是技术债务的最大根源。

那是否有好的办法把需求质量有效得提高?解决需求当然有许许多多的办法,下面是几种常见的方式:

  • 从TDD(测试驱动开发)引申出来的ATDD(Acceptance Test Driven Development: 验收测试驱动开发)。就是把TDD对开发者的成功经验挪到测试团队中,让测试人员在项目中起主导地位。
  • BDD(Behavior Driven Development:行为驱动开发)就是强调先搞清楚功能的业务需求,有它来指导后续的开发。
  • FDD(Feature Driven Development特性驱动开发)在FDD中,Feature(特性)是一个基本的开发单位,是用户眼中最小的有用的功能,可以在很短时间内实现(一般在两周之内)。
  • 实例化需求(Specification by Example):顾名思义就是要用例子的方式去阐述需求,这个概念是由Gojko Adzic提出的。

从本质上来说,实例化需求和ATDD、BDD、FDD包括其他的敏捷测试都是一个范畴。相比其他几个实践,实例化需求出现的较晚,最近几年才开始推广,我曾经所在的项目组也是2015年底才开始推广的。但它提出了更好的实践方式,减少了对工具的依赖,更容易被接受。

主要过程模式

在【实例化需求】一书中,Gojko提出了实例化需求的主要过程模式

主要过程模式主要包括以下几个重要环节:

  1. 从目标中获取范围:要一直牢记商业价值,为什么要做。很多时候执行项目时太关注怎么做了。
  2. 用例子来协作探讨需求:例子能更好得把需求描述清楚,不能含糊。
  3. 提炼需求说明:通过例子了解需求后就可以提炼出需要的需求说明。
  4. 执行需求说明并自动化:需求说明如果能执行并放入到持续集成后,信息就不会过期。
  5. 活文档:文档要长久,就必须要容易维护,从需求说明中自动产生出的活文档是最有效的方式。

举个例子:

需求主题:买书免运费

需求描述:提供读者买书优惠活动,买书超过(含)6本以上而且只含书的订单,可以免费送货到除西藏省,青海省的大陆地区。

关键例子:

  • 一个普通客户买6本书,送货地址到上海,免运费。
  • 一个普通客户买6本书,送货地址到西藏,运费大于0
  • 一个普通客户买5本书,运费大于0。
  • 一个普通客户买6本书和一个U盘,送货地址到上海,运费大于0

下一贴详细介绍这个网上书店买书免运费的例子。

敏捷开发2.0

阅读数 33

什么是敏捷开发

阅读数 256

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