不管是传统的还是敏捷的需求开发阶段，需求的层级及组成，其基本特性是一致的，这反映方法的差异并不改变需求的本身属性。一般的需求三个层次，忽略了一个问题，即每个层次所需的知识、技能、经验、背景等是不同的，不同的层次过程中，需要不同资源的整合。业界相关的论述中，只是给出了笼统的需求分析人员的统一角色，但并未对其作出区别。实际上，这很难映射到中小企业的现实操作层面。
这引发了我们进入详细的敏捷需求分析话题中第一个问题，需求的参与者如何定义？
[b]1、需求的参与者[/b]
敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。在《敏捷宣言》（Manifesto for Agile Software Development）中[3]，强调了客户一起现场工作的重要性。而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA——如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。但应该清楚，这种纳入并不能真正代替真实的客户参与。
对于客户无法全程现场参与的情况，BA的出现是一种弥补。BA最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事（user story）并将需求传递给开发人员。同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptance test）。而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。当然，这项工作可以分解为另外的角色来进行。
开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。一个完整描述的用例可以很方便地导出测例（test case）。而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。从整个过程来说，分析和实现的过程就是场景拟合和检验，以及类似于XP中结对式的及时纠偏。各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，就可以全能地做出需求定义。
[img]http://dl.iteye.com/upload/attachment/0066/7881/3485a883-ba8f-34c7-8a82-1f2e5da0ac88.png[/img]
[b]2、敏捷需求分析工作形式[/b]
敏捷宣言强调了客户在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得项目更加成功。比如，敏捷联盟所推荐的现场客户工作。但多数情况下，客户都是很忙碌的，很难全力投入到过程中。这时候，我们就需要BA这个角色，来充当客户的角色。
BA的参与使他变成了需求的组织者，需要使需求分析过程中具备资源快速聚合的能力。而工作方式，在传统之外，可以使用聚议和需求迭代计划会议的形式。
敏捷思想的核心是人与人的交流。聚议是一种面对面的最好形式，它能促成问题从多个角度的现场核清。在前期的高层访谈之后，需求分析过程中至少要有以下的准备：（1）明确业务价值及其所推导的业务场景；（2）范围划分使得每个议题都有独立的业务价值，对于大而笼统的“需求”，则分解或置入下次迭代，而本次完成的将是一个相对完整的结果。对于需求分析中所用的各种形式，用户其实并不排斥参与——尤其是当他掌握了一定方法并能看到迅速回应带来的好处时，将极大地提升这种兴趣。在某省电信运营商的项目中，我们已经发现了这一点。用户明白积极参与的好处时，能主动从业务角度审视自己的需求，删减调整并作出易理解的文档。在一个已经实施的项目中做增量改进时，用户参与尤为重要，并且能部分地把前端人员从繁琐而低效的沟通（其实只是“传话筒”）和文档化中解脱出来。
迭代是敏捷最显著的形式，而迭代的前提，则是对业务价值分解为用户故事的工作。这些将在下文中讨论。迭代计划会议是一种需求组织方式，在每个迭代开始的时候，由BA主持召开迭代计划会议，在会议上向开发人员解释这个迭代要完成的用户故事，然后由开发人员自由提问，知道他们能够获得足够开始实现该功能的信息。包括了用户参与的需求分析迭代会议，则可适时地作出review，避免错误的扩大和带入下次迭代。
[b]3、需求分析时机[/b]
传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。
敏捷需求分析对这种惯例做出调整，源于其认为：需求的逐步细化过程中，变更是不可避免的；同时，为了快速的商业响应，保证能产出可见、可执行的结果也是必要的。后续的迭代和持续集成保证了需求的演进路线，简言之，需求分析贯穿于项目的整个生命周期。
[b]4、需求的划分[/b]
开发人员总是希望能明确地知道系统分几个模板，功能是什么，但这些信息并不是需求的本身。基于模块和功能分解，专门的需求分析人员会使之流于粗放——这种情况是最多见的，功能划分使需求单位粒度较大，不足以描述其特征；而传统由开发人员来做的分析，往往会越过业务价值层面而转入底层的设计。
敏捷需求分析中的划分，将以独立业务价值为基础，划分为一个个用户故事（可以去类比理解UP意义上的use case），它可以是很小颗粒的业务与特征集，也可能会跨越传统的子模块边界。用户故事以参与者为中心，描述了参与者“作为（系统的一个涉众），想要（做一件事），从而（达到一个业务价值）[7]”的集合。用户故事是可见的业务价值，而不是功能描述。每个用户故事的粒度和开发工作量都相差不多，这是其与用例的区别。以此构建的测例，将指导测试与需求验证。
[b]5、敏捷需求分析与细化过程[/b]
迭代是敏捷需求分析与细化过程中最显著的方式。迭代的特征包含如前文所述的两部分：全生命过程、小粒度的以业务价值为基础的划分。Robert C. Martin认为每一次迭代都是一个完整的项目产品[3]，换言之，迭代是要产生最终产品的反复[4]，也就是说你的一次一次的反复必须都能产生最终的产品，而不是中间的半成品。这也反映了需求划分的原则，以及每一次小的迭代，其结果都是可确认的。因此，迭代过程中重要的一种方法是分解，以及关注于当前价值实现的部分。如果一个需求暂时不能被理解并且与当前的商业目标的关系并不那么直接，那么它应该被分解和延后，而不是草草地做一个似是而非的大方案而囊括之。
迭代是一种快速反应和逐步确认成果的方式。敏捷意味着快速反应、注重核心价值， 但并不是要求每件事都尽快地完成和提交。迭代计划的依据便是优先级的确定。因此，迭代的实施要求正确引导客户划分优先级，实施逐步的集成改进。必要时，项目上线也是可以逐步推行的，因为仅仅上线并不意味着价值的实现。
传统的需求分析总是希望能一定完成所有的事情以便于直接作出功能划分和设计，但这在我们以往经历的项目实践中遇到了挑战，不得不把项目的需求分析肢解成似乎是多个不同项目的需求集合。敏捷而持续的过程，对此作出修正。
[b]6、文档与变更[/b]
正如Martin对那种什么文档也不写就自称为敏捷的善意批评[3]，敏捷过程对文档的态度只是一种思想的转变，而非重型的过程控制要求。敏捷方法需要两种类型的文档，它们分别是需求文档和设计文档，而其它所有类型的文档都是选择性的。对于需求文档，在敏捷方法中，往往会在某次迭代之中进行。它经常先于其他开发过程，但也要到开发过程的迭代开始的时候才在内容上达到完整。对于暂时不做的开发，就不会做细部特征的定义，以免浪费。撰写文档，其实是一件颇耗精力的事情，所以选择做什么样的文档需要有一种“投资回报”的考虑。
传统的大量正式文档，规格严整而厚重，但在项目的中后期却往往不能保持同步（现状、文档之间以及与软件系统），难以维护和跟踪，生产和维护成本也很高。这些文档除表明需求本身外，更多地是一种管理控制的角色，比如，对于变更。
敏捷过程并不是由文档主导、支撑和控制变更。如《敏捷宣言》中所透露的“响应变化胜过遵循计划” [3]，对于变更，敏捷过程是一个态度的转变。变更除过软件工程组织或者PMI等定义大部分类似于由“工作缺陷”引起的以外，在现代信息化竞争时代，它往往意味着商机。当然，对于这种商机的“欢迎”，企业需要商务模式的准备，否则将极易陷入“需求黑洞”之中。
[b]7、敏捷需求分析小结[/b]
[img]http://dl.iteye.com/upload/attachment/0066/7893/87d28c15-bf70-3e35-a04b-53cde0a9c696.png[/img]
8、总结
敏捷需求分析参与生命周期的迭代，而每一次迭代都是一个完整的过程，并产生项目交付品，而在下一个迭代之前，其交付品都是可用的。这种方法能有效地及时调整，从源头消除可能被放大的缺陷。
敏捷过程中，需要BA、QA的全程参与（当然，在企业实践中，可能存在着职能划分的现状。从更有效的角度看，由于项目经理参与了项目全生命周期，尤其是对需求管理的全过程的跟踪，项目经理担任某一项目的BA角色，也是现实可行的，其优点是可以保证有及时的客户沟通、长期而细致的跟踪），保证需求能始终被正确地理解、传递和验证。从敏捷需求出发导出的场景拟合验收测试，能从更广阔的层级（业务价值视角）来验证需求的达成性而不仅仅是软件的可用性等指标。这对质量保证是一个提高。迭代演进中应对需求变更，是从客户视野上的更高的质量改进。
原文：http://www.uml.org.cn/SoftWareProcess/201111101.asp
这引发了我们进入详细的敏捷需求分析话题中第一个问题，需求的参与者如何定义？
[b]1、需求的参与者[/b]
敏捷需求分析过程的参与者，包括客户/用户、需求分析人员（业界一般也称之为商务分析师或业务分析师，business analyst，本文并不讨论词汇的细致差异，下文统一简称BA）、开发人员、测试人员，其他相关的角色有项目管理者等。在《敏捷宣言》（Manifesto for Agile Software Development）中[3]，强调了客户一起现场工作的重要性。而在企业实际的实施过程中，由于限制，项目经理及实施人员，以及BA——如果有的话，在虚拟团队中，他们演绎客户的角色，从而使得“客户”也更好地“纳入”到了项目团队中。但应该清楚，这种纳入并不能真正代替真实的客户参与。
对于客户无法全程现场参与的情况，BA的出现是一种弥补。BA最重要的职责就是与客户交谈，了解和分析需求，将其制作成用户故事（user story）并将需求传递给开发人员。同时，BA也要在某种参与度较深的情况下代替客户负责功能验收测试（Acceptance test）。而对内，BA显然扮演了客户，那么除了需求提供者的职责，如果需要的话，相应地也要有评价和验收否决的权利。当然，这项工作可以分解为另外的角色来进行。
开发、测试人员进入需求团队，便于他们理解用户故事或者典型的RUP式的用例。一个完整描述的用例可以很方便地导出测例（test case）。而用例和测例是一致的，它描述在一个具体业务场景中可见的需求特征。我们可以根据这样的可见性写出功能测试，从而驱动这个用户故事的开发，这被称为 Acceptance Driven Development。从整个过程来说，分析和实现的过程就是场景拟合和检验，以及类似于XP中结对式的及时纠偏。各种角色的积极参与在不同角度和层次下的场景拟合，表明需求不是程序员的事情，也不是寄望于抽象出一个BA的角色甚至实例化为一个职位，就可以全能地做出需求定义。
[img]http://dl.iteye.com/upload/attachment/0066/7881/3485a883-ba8f-34c7-8a82-1f2e5da0ac88.png[/img]
[b]2、敏捷需求分析工作形式[/b]
敏捷宣言强调了客户在一起工作的重要，敏捷是大家在一起高效率地工作，清楚所有沟通上的障碍，关注于增值的活动，从而使得项目更加成功。比如，敏捷联盟所推荐的现场客户工作。但多数情况下，客户都是很忙碌的，很难全力投入到过程中。这时候，我们就需要BA这个角色，来充当客户的角色。
BA的参与使他变成了需求的组织者，需要使需求分析过程中具备资源快速聚合的能力。而工作方式，在传统之外，可以使用聚议和需求迭代计划会议的形式。
敏捷思想的核心是人与人的交流。聚议是一种面对面的最好形式，它能促成问题从多个角度的现场核清。在前期的高层访谈之后，需求分析过程中至少要有以下的准备：（1）明确业务价值及其所推导的业务场景；（2）范围划分使得每个议题都有独立的业务价值，对于大而笼统的“需求”，则分解或置入下次迭代，而本次完成的将是一个相对完整的结果。对于需求分析中所用的各种形式，用户其实并不排斥参与——尤其是当他掌握了一定方法并能看到迅速回应带来的好处时，将极大地提升这种兴趣。在某省电信运营商的项目中，我们已经发现了这一点。用户明白积极参与的好处时，能主动从业务角度审视自己的需求，删减调整并作出易理解的文档。在一个已经实施的项目中做增量改进时，用户参与尤为重要，并且能部分地把前端人员从繁琐而低效的沟通（其实只是“传话筒”）和文档化中解脱出来。
迭代是敏捷最显著的形式，而迭代的前提，则是对业务价值分解为用户故事的工作。这些将在下文中讨论。迭代计划会议是一种需求组织方式，在每个迭代开始的时候，由BA主持召开迭代计划会议，在会议上向开发人员解释这个迭代要完成的用户故事，然后由开发人员自由提问，知道他们能够获得足够开始实现该功能的信息。包括了用户参与的需求分析迭代会议，则可适时地作出review，避免错误的扩大和带入下次迭代。
[b]3、需求分析时机[/b]
传统的需求分析时机集中在项目前期，总是遵循前期调研—分析—需求定义，转给开发后需求工作便就此结束，其思想里，便是一次性完整、清楚地做完所有层次的需求，并在整个过程中遵循计划。
敏捷需求分析对这种惯例做出调整，源于其认为：需求的逐步细化过程中，变更是不可避免的；同时，为了快速的商业响应，保证能产出可见、可执行的结果也是必要的。后续的迭代和持续集成保证了需求的演进路线，简言之，需求分析贯穿于项目的整个生命周期。
[b]4、需求的划分[/b]
开发人员总是希望能明确地知道系统分几个模板，功能是什么，但这些信息并不是需求的本身。基于模块和功能分解，专门的需求分析人员会使之流于粗放——这种情况是最多见的，功能划分使需求单位粒度较大，不足以描述其特征；而传统由开发人员来做的分析，往往会越过业务价值层面而转入底层的设计。
敏捷需求分析中的划分，将以独立业务价值为基础，划分为一个个用户故事（可以去类比理解UP意义上的use case），它可以是很小颗粒的业务与特征集，也可能会跨越传统的子模块边界。用户故事以参与者为中心，描述了参与者“作为（系统的一个涉众），想要（做一件事），从而（达到一个业务价值）[7]”的集合。用户故事是可见的业务价值，而不是功能描述。每个用户故事的粒度和开发工作量都相差不多，这是其与用例的区别。以此构建的测例，将指导测试与需求验证。
[b]5、敏捷需求分析与细化过程[/b]
迭代是敏捷需求分析与细化过程中最显著的方式。迭代的特征包含如前文所述的两部分：全生命过程、小粒度的以业务价值为基础的划分。Robert C. Martin认为每一次迭代都是一个完整的项目产品[3]，换言之，迭代是要产生最终产品的反复[4]，也就是说你的一次一次的反复必须都能产生最终的产品，而不是中间的半成品。这也反映了需求划分的原则，以及每一次小的迭代，其结果都是可确认的。因此，迭代过程中重要的一种方法是分解，以及关注于当前价值实现的部分。如果一个需求暂时不能被理解并且与当前的商业目标的关系并不那么直接，那么它应该被分解和延后，而不是草草地做一个似是而非的大方案而囊括之。
迭代是一种快速反应和逐步确认成果的方式。敏捷意味着快速反应、注重核心价值， 但并不是要求每件事都尽快地完成和提交。迭代计划的依据便是优先级的确定。因此，迭代的实施要求正确引导客户划分优先级，实施逐步的集成改进。必要时，项目上线也是可以逐步推行的，因为仅仅上线并不意味着价值的实现。
传统的需求分析总是希望能一定完成所有的事情以便于直接作出功能划分和设计，但这在我们以往经历的项目实践中遇到了挑战，不得不把项目的需求分析肢解成似乎是多个不同项目的需求集合。敏捷而持续的过程，对此作出修正。
[b]6、文档与变更[/b]
正如Martin对那种什么文档也不写就自称为敏捷的善意批评[3]，敏捷过程对文档的态度只是一种思想的转变，而非重型的过程控制要求。敏捷方法需要两种类型的文档，它们分别是需求文档和设计文档，而其它所有类型的文档都是选择性的。对于需求文档，在敏捷方法中，往往会在某次迭代之中进行。它经常先于其他开发过程，但也要到开发过程的迭代开始的时候才在内容上达到完整。对于暂时不做的开发，就不会做细部特征的定义，以免浪费。撰写文档，其实是一件颇耗精力的事情，所以选择做什么样的文档需要有一种“投资回报”的考虑。
传统的大量正式文档，规格严整而厚重，但在项目的中后期却往往不能保持同步（现状、文档之间以及与软件系统），难以维护和跟踪，生产和维护成本也很高。这些文档除表明需求本身外，更多地是一种管理控制的角色，比如，对于变更。
敏捷过程并不是由文档主导、支撑和控制变更。如《敏捷宣言》中所透露的“响应变化胜过遵循计划” [3]，对于变更，敏捷过程是一个态度的转变。变更除过软件工程组织或者PMI等定义大部分类似于由“工作缺陷”引起的以外，在现代信息化竞争时代，它往往意味着商机。当然，对于这种商机的“欢迎”，企业需要商务模式的准备，否则将极易陷入“需求黑洞”之中。
[b]7、敏捷需求分析小结[/b]
[img]http://dl.iteye.com/upload/attachment/0066/7893/87d28c15-bf70-3e35-a04b-53cde0a9c696.png[/img]
8、总结
敏捷需求分析参与生命周期的迭代，而每一次迭代都是一个完整的过程，并产生项目交付品，而在下一个迭代之前，其交付品都是可用的。这种方法能有效地及时调整，从源头消除可能被放大的缺陷。
敏捷过程中，需要BA、QA的全程参与（当然，在企业实践中，可能存在着职能划分的现状。从更有效的角度看，由于项目经理参与了项目全生命周期，尤其是对需求管理的全过程的跟踪，项目经理担任某一项目的BA角色，也是现实可行的，其优点是可以保证有及时的客户沟通、长期而细致的跟踪），保证需求能始终被正确地理解、传递和验证。从敏捷需求出发导出的场景拟合验收测试，能从更广阔的层级（业务价值视角）来验证需求的达成性而不仅仅是软件的可用性等指标。这对质量保证是一个提高。迭代演进中应对需求变更，是从客户视野上的更高的质量改进。
原文：http://www.uml.org.cn/SoftWareProcess/201111101.asp
扫一扫
647
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
