精华内容
参与话题
问答
  • 敏捷需求分析

    千次阅读 2007-07-16 16:39:00
    在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱的...敏捷过程到底是如何做需求分析?用户故事和用例有什么区别?敏捷过程如何去管理需求的?这些是一些想要实践敏捷的人一直在困惑的事情。 我们

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

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

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

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

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

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

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

      在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更?

      搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。

      举一个最常见的用户故事例子,"作为一个普通用户,我希望能够用用户名和密码登录,以便我能享受到个性化的服务"。其中,用户是系统涉众,登录是他想要做的事情,而他的目标是获得个性化的服务。

          从这个例子我们可以想象到,这个页面可能存在两个文本框,用于输入用户名和密码,有一个按钮来登录,并且不登录就不能看到个人资料,另外,如果用户输入错误需要提示"登录失败请重试"。这就是可见性,也可以称为可测试性。我们可以根据这样的可见性写出功能测试,从而驱动这个用户故事的开发,这被称为 Acceptance Driven Development。

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

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

      ThoughtWorks有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目,在开工的时候客户对功能需求还不明确,但需要快速推出抢占市场,正是最适合敏捷过程的项目。

      在项目伊始,商务分析师和客户做了深入的谈话,了解他的商业构想,他的盈利模式,搞清楚宏观的结构,然后思考并整理获得的结果,花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善,不足以做好整个系统。但对于我们开始项目的前一阵,已经足够了。我们可以从这里开始项目。

      敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前,由一组有经验的开发人员大致评估一下用户故事,标记出不同的难度和风险,并提出问题供商务分析师来获得更详细的信息,商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选,客户可以选择这些用户故事,或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。

      客户看到每个迭代交付的可运行的软件后或者得到用户反馈后,常常会有新的想法冒出来。有些想法是好的,有些想法就属于看到别家网站有这个功能,不假思索的提出的功能。这些不同的需求都需要经过认真的分析,找出哪些是值得我们立即考虑的,哪些是不用急迫的去实现的。

      有一次和客户谈话时,他说到希望增加拍卖功能。那么,我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑,我们发现,网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求,因此,用户最终放弃了这个特性。

      另一次,客服人员提出增加一个查询用户交易的功能,而此时我们有其他更加重要的功能需要先去考虑,查询用户交易功能可以由技术人员临时通过数据库直接代为查询,因为项目运营初期交易不是很多,暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上,始终没有排到最高的优先级。

      客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合,客户也逐渐适应了许多敏捷思想,甚至我在和客户讨论时,偶然提起了后期的某种可能的情况,他们还能够帮我纠正应当考虑目前的情况,为近期的情况作计划。
            用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展,是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后,团队的开发速度基本保持恒定,我们就可以很容易的知道每个迭代能做多少个用户故事,这样就可以安排下一迭代的开发。

      每个迭代内分析好恰好足够下一个迭代开发的需求,就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成,包括需求的了解,分析,评估和排列优先级。

      在每个迭代开始的时候,由商务分析师主持召开迭代计划会议,在会议上向所有的程序员解释这个迭代要完成的用户故事,然后由程序员自由提问,知道他们能够获得足够开始实现该功能的信息。

      在程序员完成一个用户故事后,商务分析师还要来代表客户做功能验收测试,查看是否完成了预计的功能,是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然,更多的测试还需要QA来完成。

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

    展开全文
  • 敏捷需求分析

    千次阅读 2006-12-26 13:28:00
    (本文发表于程序员杂志2006年第4期)在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是程序员最爱...敏捷过程到底是如何做需求分析?用户故事和用例有什么区别?敏捷过程如何去管理需求的?这些是一些想要实

    (本文发表于程序员杂志2006年第4期)

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

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

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

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

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

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

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

    在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更?

    搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。

    举一个最常见的用户故事例子,"作为一个普通用户,我希望能够用用户名和密码登录,以便我能享受到个性化的服务"。其中,用户是系统涉众,登录是他想要做的事情,而他的目标是获得个性化的服务。

    从这个例子我们可以想象到,这个页面可能存在两个文本框,用于输入用户名和密码,有一个按钮来登录,并且不登录就不能看到个人资料,另外,如果用户输入错误需要提示"登录失败请重试"。这就是可见性,也可以称为可测试性。我们可以根据这样的可见性写出功能测试,从而驱动这个用户故事的开发,这被称为 Acceptance Driven Development。

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

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

    ThoughtWorks有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目,在开工的时候客户对功能需求还不明确,但需要快速推出抢占市场,正是最适合敏捷过程的项目。

    在项目伊始,商务分析师和客户做了深入的谈话,了解他的商业构想,他的盈利模式,搞清楚宏观的结构,然后思考并整理获得的结果,花1-2天时间将客户需求大略整理为几十个用户故事。这些用户故事并不完善,不足以做好整个系统。但对于我们开始项目的前一阵,已经足够了。我们可以从这里开始项目。

    敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前,由一组有经验的开发人员大致评估一下用户故事,标记出不同的难度和风险,并提出问题供商务分析师来获得更详细的信息,商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选,客户可以选择这些用户故事,或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。
    客户看到每个迭代交付的可运行的软件后或者得到用户反馈后,常常会有新的想法冒出来。有些想法是好的,有些想法就属于看到别家网站有这个功能,不假思索的提出的功能。这些不同的需求都需要经过认真的分析,找出哪些是值得我们立即考虑的,哪些是不用急迫的去实现的。

    有一次和客户谈话时,他说到希望增加拍卖功能。那么,我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑,我们发现,网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求,因此,用户最终放弃了这个特性。

    另一次,客服人员提出增加一个查询用户交易的功能,而此时我们有其他更加重要的功能需要先去考虑,查询用户交易功能可以由技术人员临时通过数据库直接代为查询,因为项目运营初期交易不是很多,暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上,始终没有排到最高的优先级。

    客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级的做法。但经过几个月的磨合,客户也逐渐适应了许多敏捷思想,甚至我在和客户讨论时,偶然提起了后期的某种可能的情况,他们还能够帮我纠正应当考虑目前的情况,为近期的情况作计划。

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

    每个迭代内分析好恰好足够下一个迭代开发的需求,就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成,包括需求的了解,分析,评估和排列优先级。

    在每个迭代开始的时候,由商务分析师主持召开迭代计划会议,在会议上向所有的程序员解释这个迭代要完成的用户故事,然后由程序员自由提问,知道他们能够获得足够开始实现该功能的信息。

    在程序员完成一个用户故事后,商务分析师还要来代表客户做功能验收测试,查看是否完成了预计的功能,是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然,更多的测试还需要QA来完成。

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

     
    展开全文
  • 放眼望去,在当今软件工程领域出现的许多问题,诸如缺陷及...什么是敏捷需求分析?产品级和项目级需求有何异同?敏捷需求分析方法论中的五大关键点是什么?就以上热点话题,雅各布森中国区总经理吴穹分享了他的看法。
  • 所以,我萌发了分享关于如何进行敏捷需求分析的念头,希望能让大家了解需求分析的“套路”,规范需求分析的产出。 17年1月初,我给团队以及公司内其他同事就这个话题做了第一次分享。分享完了还意犹未尽,就想把

    16年7月份的时候,我接手了一个产品研发团队。团队中有一些人有比较好的需求分析的sense,能够设计出很合理的用户界面,但是其他的文字性产出就五花八门;在面临一个完整的业务时,也无法由浅入深的去剖析。所以,我萌发了分享关于如何进行敏捷需求分析的念头,希望能让大家了解需求分析的“套路”,规范需求分析的产出。 17年1月初,我给团队以及公司内其他同事就这个话题做了第一次分享。分享完了还意犹未尽,就想把分享的内容用博客的形式展现出来。

    软件需求分析是一个比较大的话题,仅仅通过一两篇博客肯定无法说清楚。所以我想通过闲谈的方式,与大家聊一聊这个话题,知道多少聊多少吧,但愿可以有些作用。

    作为软件研发流程中的其中一个环节,软件需求分析也是有流程的,如果我们按照这样的流程去分析软件需求,一般都可以分析的八九不离十。这个就是人们常说的“套路”。从2012年开始接触敏捷开发,到现在5年多的时间一直都在带团队做敏捷项目,自己也比较沉迷于此,所以,今天主要想聊聊敏捷需求分析的“套路”。除去项目管理相关的流程,我认为敏捷需求分析流程应该如下图所示。



    任何软件项目的需求,最初肯定都是由老板(投资人)提出来的,带有明确的商业目的。比如,通过向市场销售获取商业回报;又比如,通过软件提高管理效率,缩减管理成本;等等。诸如此类的需求,我们可以定义为“商务需求”。商务需求可以用User Story的标准格式来表述。有了最初的商务需求,接下来业务分析人员(BA)就应该开始忙活了。

    首先需要进行业务架构分析。这个过程中需要辨别系统需要处理哪些业务,每个业务都有哪些人参与,业务流程是怎样的。这个过程结束后应该有两个产出,一个是业务框架图,另一个是每个业务的流程图;接下来需要做的工作是业务模块分解,对照着业务流程图,业务模块往往是流程图中某个步骤或者某几个步骤的合并。这个过程的产出是在业务框架图的基础上生成业务模块矩阵。业务模块分解完成后,可以用User Story的格式对业务模块矩阵中的每个模块进行描述,从而形成“业务模块需求”。业务架构分析与业务模块分解的过程中,BA需要与具体业务人员进行深入沟通,了解业务的每个细节。业务模块需求产生后,接下来需要针对每个业务模块, 进行业务场景分解。这个过程会涉及到一些技术范畴的内容,实现某种业务的场景可能会有多种,在不影响用户体验的前提下,尽量使用相对比较容易实现的场景。从这个时候开始,需要有技术人员的参与,以尽早避免一些技术性风险。业务场景分解完成后,每个场景就是相对应的“业务场景需求”,这种需求也可以用User Story的格式书写。业务场景需求是面向实现层面的,如果BA人员要偷懒,有了这个需求,开发人员也可以进行开发了,但是口头沟通的成本会很高,所以还需要接着往下分析。场景流程分析与界面设计是两个必要的步骤(当然,对于某些没有用户交互的功能,界面设计可以省略)。这两个步骤很难说一定是谁先谁后,但是界面设计完成后,基本上场景流程也就确定了,所以从思维的进展方向考虑,我倾向于把场景流程分析放在前面。这两个过程需要技术人员的深度参与, 比如说用户管理中的用户登录功能,考虑与未考虑安全性因素,分析出来的结果完全不同。需求分析做到这里,加上少量的口头沟通,基本上已经可以满足技术开发的要求了。事实上,很多敏捷项目也都是这样做的。这样的需求,对于衡量测试覆盖率这样的指标还有些困难,所以考虑到软件质量,最好再往下做一步,即“需求条目化”。我的理解,“需求条目化”是针对每个业务场景需求,给出具体的接受条件。这种接受条件也有标准的书写格式,用Given/When/Then这样的三段式来表述,测试人员需要为每个条件写一个或多个测试用例。我认为,为了提高软件质量,“需求条目化”这个步骤是必要的,但是,要完成这个步骤需要的工作量不小,对于小规模的敏捷团队要求比较高。我正在我的团队中实施这个步骤,具体效果如何还要时间检验。

    以上是我对敏捷软件需求分析流程做的一个简单总结,“商务需求”,“业务模块需求”和“业务场景需求”是我针对需求分析三个层次的不同产出给出的不同定义。

    展开全文
  • 敏捷需求分析的感慨

    2010-09-09 21:24:41
    敏捷需求分析 今天与范同学偶然聊到点感触... 记录之 敏捷采用的迭代式需求分析带来的好处已经不言而喻。迭代式需求分析首先引入项目快速启动,确定整个项目的范畴和相对模糊的系统架构,然后得到...

    敏捷需求分析

    今天与范同学偶然聊到点感触... 记录之

    敏捷采用的迭代式需求分析带来的好处已经不言而喻。迭代式需求分析首先引入项目快速启动,确定整个项目的范畴和相对模糊的系统架构,然后得到熟知的Master story list. 在随后的迭代过程中,需求被逐步细化,直至精确的描述用户商业价值。迭代分析过程也是不断帮助用户探索商业模式,寻求商业价值的过程。用户基于已经发布的系统提出反馈,变更需求成为了可能。

    但在实践过程中,我们也看到被很多团队滥用。这并不意味着迭代式需求分析存在问题,迭代分析的前提是,假设需求是无法一次并且准确的确定,为规避前端预测型分析思路带来的风险不得不采用这种模式。一些密切结合实际商业环境的项目多是满足这样的前提,例如商业网站

    但是,对于项目前期就能明显确定需求的项目,是否一定要采用迭代方式?答案显然是否定的。对于需求变更,我们采用系统重构来解决,但重构总归会带来修改系统的成本,比如变化架构,修改数据等,如果能够一次性确定准确的需求,大可不必一定要放在后期迭代。纵观所我所经历的项目,这样的项目还真的不少,比如基于电信计费的数据平台,数据仓库架构的报表和数据挖掘系统,尽管这些系统还是有需求变更,但变更规模很小,前期分析的准确度还是相当的高的,在成本和风险的权衡中,风险已经不能成为问题。

    以前也有过很多关于瀑布模型和敏捷项目开发的讨论。常有这样的说法:瀑布模型未必不能带来项目的成功,敏捷开发也未必能保障项目一定成功(这是一个巧妙且安全的说法)。一个成功的项目需要有很多种因素,人,团队,客户,技术,资源,商业环境,业务模式,合作方式,等, 而失败的项目只需要破坏一项因素就可以了,又一次验证木桶理论!那如何决定你用瀑布模型,还是迭代式方法?其中之一就是对项目性质的了解, 对于需求原本就明确的项目,对于建立在稳定的组织流程上的项目,在快速启动阶段多做些精确需求性质的工作也是不错的选择。这样的项目多侧重技术和组织层面。而其他的侧重商业应用,市场行为的项目,多采用迭代式分析是必须的。

    现在似乎进入了另一个误区:某些项目还是需要用瀑布模型来解决。并非如次!瀑布模型总归会逐渐体现它的弊端,而敏捷也并非就仅仅指迭代式开发。实践过程还得活学活用,书本会把敏捷包装成一个包裹,给读者的感觉是要么不用,要么全用。而实际情况多种多样,裁剪敏捷必不可少,择其适者而为之是团队和PM的职责,至于来源哪里,以前的瀑布?流行的敏捷?精艺思想?已经不再重要。

    把应用敏捷当作照剧本演戏是不足取的!!

    [@more@]

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7501538/viewspace-1038125/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/7501538/viewspace-1038125/

    展开全文
  • 未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在於每一 个用户故事都是一个“可独立分配”的需求(特徵)单位。要达到“可独立分配”,就要从“用户”如何使用系统...
  • Re: 敏捷需求分析

    2006-11-20 11:06:54
    因为需求一开始并没有清楚. 对于公司要后期调整人员变动, 或者新项目等不明确. 希望在这方面说一下. 谢谢[/quote] 现在的项目,尤其是web需要运营类的,很难定义什么时候是完成。因为项目很快就上线,之后...
  • 敏捷开发中,全体成员都会参与需求分析。但是,通常多数的开发人员和测试人员他们的能力和经验不足以胜任需求分析工作。这意味着全体成员参与的需求分析活动需要一个扮演导师角色的人带领大家去进行有效的需求分析。...
  • 原文转自:http://www.systhinker.com/html/81/n-21681.html 大多数学计算机语言的人都会有过这样的感受,过去一直认为编程和架构是整个软件生命周期里最了不起的部分,但实际工作后才会发现...什么是敏捷需求分析?产
  • 不管是传统的还是敏捷的需求开发阶段,...业界相关的论述中,只是给出了笼统的需求分析人员的统一角色,但并未对其作出区别。实际上,这很难映射到中小企业的现实操作层面。 这引发了我们进入详细的敏捷需求分...

空空如也

1 2 3 4 5 ... 20
收藏数 1,486
精华内容 594
关键字:

敏捷需求分析