与传统软件开发人员一样，敏捷软件开发人员也会执行分析活动。与传统开发人员不同，敏捷专家以高度协作的方式进行分析，并在即时（JIT）基础上进行分析。分析对我们来说非常重要，我们每天都会这样做。在本文中，我将讨论：

• 什么是分析？
• 什么是敏捷分析？
• 通过敏捷生命周期进行分析
• 潜在的分析模型
• 重新思考分析师的角色
• 结论

1.什么是分析？

分析的目的是了解将要构建什么，为什么要构建，构建（估计）可能花费多少，以及构建它的顺序（优先级）。>这类似于需求获取，其目的是确定用户想要构建的内容。主要区别在于需求收集的重点是了解用户及其对系统的潜在用途，而分析的重点则转移到了解系统本身和探索问题域的细节。另一种分析方法是，它代表了需求和设计之间的中间环节，即思维模式从需要构建的过程转变为构建方式的过程。

2.什么是敏捷分析？

让我们首先描述敏捷分析不是：

• 它不是项目生命周期中的一个阶段
• 这不是您项目进度的任务
• 它本身并不是一种手段

什么是敏捷分析？从前面关于敏捷业务系统分析师所做的讨论开始，您的敏捷分析工作应该具有以下特征：

• 敏捷分析应该是沟通丰富。敏捷开发人员更喜欢温暖的通信技术，如面对面讨论和视频会议，而不是文档和电子邮件等冷技术，如“通信”文章中所述。敏捷开发人员倾向于尽可能密切地与项目利益相关者合作，尽可能遵循AM的积极利益相关者参与实践。
• 敏捷分析是高度迭代的。正如Martin（2002）指出的那样，分析和设计活动都是相互依赖的：估算是分析的一部分，但依赖于某些设计被执行以确定如何实现某些东西，而您的设计工作依赖于执行足够的分析来定义什么需要建立。因此，分析是迭代的。
• 敏捷分析是渐进式的。> Martin（2002）也正确地指出敏捷分析是渐进式的，您不需要一次性构建系统。这种理念支持通用敏捷软件过程所支持的增量方法，其中工作被分解为小的，可实现的“功能块”。这些块应该在很短的时间内实现，通常只需要几小时或几天。
• 敏捷分析探索并阐明了问题空间。您的主要目标是识别和了解项目利益相关者对您系统的需求。此外，需要将此信息传达给参与项目的每个人，包括开发人员和利益相关者。这有助于理解并同意项目的整体愿景。
• 敏捷分析包括对需求的估计和优先级排序。在对需求进行估算和优先排序时，软件开发对项目利益相关者来说变得“真实”。很容易说你想要的东西，但很难同意它的价格，更不用说交换它对你来说更重要的东西。
• 敏捷分析会产生足够好的工件。如果敏捷分析的结果是创建任何工件（您将遵循AM练习，毕竟丢弃临时模型），它们应该是敏捷模型或敏捷文档。这些文物通常远非完美，它们只是勉强实现其目的而已。

以下是我对敏捷分析的定义：

敏捷分析是高度渐进和协作的过程，开发人员和项目利益相关者积极地在即时（JIT）基础上协同工作，以了解域，识别需要构建的内容，估计功能，确定功能的优先级，并且在此过程中可选地产生几乎不够好的工件。

3.通过生命周期分析

图1描绘了敏捷模型驱动开发（AMDD）的生命周期。 在“迭代0”中，敏捷项目的第一次迭代，您需要使项目井井有条并朝着正确的方向前进。 这项工作的一部分是初步设想需求和架构，以便您能够回答有关项目范围，成本，进度和技术策略的关键问题。 在迭代期间通过在每次迭代开始时的初始迭代建模或通过在整个迭代中进行模拟计划，在实时（JIT）基础上识别关于业务域的细节。 分析对于敏捷专家来说非常重要，我们每天都会这样做。

图1.软件项目的敏捷模型驱动开发（AMDD）生命周期。

4.一些潜在的分析模型

创建的工件是否采用敏捷方法进行分析，而不是传统分析结果所创建的方法？ 在某种程度上他们是。 它们实际上是相同类型的工件，用例图毕竟是一个用例图，但它们的创建方式是不同的。 这些工件是按照AM的原理和实践创建的，它们几乎不够好，经常被丢弃以便轻装上阵。

表1列出了分析建模过程中使用的常见工件，并提出了一个简单的工具，您可以使用该工具创建此类工件。 值得注意的是，此列表具有代表性，在敏捷建模工件和敏捷建模一书中提供了更全面的列表。

表1.用于分析建模的候选工件。

Artifact	Simple Tool	Description
Activity Diagram	Whiteboard	UML activity diagrams are used during analysis modeling to explore the logic of a usage scenario (see below), system use case, or the flow of logic of a business process. In many ways activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs).
Class Diagram	Whiteboard	Class diagrams show the classes of the system, their inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. During analysis you can use class diagrams to represent your conceptual model which depict your detailed understanding of the problem space for your system.
Constraint definition	Index card	A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements for your project.
CRC model	Index cards	A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. Like class diagrams, CRC models are used during analysis modeling for conceptual modeling.
Data flow diagram (DFD)	Whiteboard	A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores. When analysis modeling a DFD can be used to model the existing and/or proposed business processes that your system will support.
Entity/Relationship (E/R) diagram (data diagram)	Whiteboard	E/R diagrams show the main entities, their data attributes, and the relationships between those entities. Like class diagrams E/R diagrams can be used for conceptual modeling, in many ways E/R diagrams can be thought of as a subset of class diagrams.
Flow chart	Whiteboard	Flow charts are used in a similar manner to activity diagrams.
Robustness diagrams	Whiteboard	Robustness diagrams can be used to analyze usage scenarios to identify candidate classes and major user interface elements (screens, reports, ...).
Sequence diagram	Whiteboard	Sequence diagrams are used to model the logic of usage scenarios. Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both explore and validate your logic.
State chart diagram	Whiteboard	State chart diagrams depict the various states, and the transitions between those states, that an entity exhibits. During analysis modeling state chart diagrams are used to explore the lifecycle of an entity that exhibits complex behavior.
System use case	Paper	A use case is a sequence of actions that provide a measurable value to an actor. A system use case includes high-level implementation decisions in it. For example, a system use case will refer to specific user interface components - such as screens, HTML pages, or reports. System use cases will also reflect fundamental architectural decisions, such as the use of ATMs versus cell phones to access your bank account.
UI prototype	Whiteboard	A user interface (UI) prototype models the user interface of your system. As a part of analysis modeling it enables you to explore the problem space that your system addresses in a manner that your project stakeholders understand. Remember, the user interface is the system to most people.
Usage scenario	Index card	A usage scenario is exactly what its name indicates - the description of a potential way that your system is used.
Use case diagram	Whiteboard	The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box. When analysis modeling a use case diagram can be used to depict the business functionality, at a high-level, that your system will support. It can also be used to depict the scope of the various releases of your system via the use of color or system boundary boxes.

5.重新思考分析师的作用

无论范例如何，分析都是任何软件开发项目的一项非常重要的活动。这是一个组织设计决策，用于定义您将拥有的角色以及这些角色将执行的操作。在传统开发中，通常有人担任分析师角色，有些组织甚至选择区分分析师类型，并且会有系统分析员（SA），业务分析师（BA），业务系统分析师（BSA），数据分析师，流程分析师等。在敏捷开发中，我们做出不同的组织设计决策。因此，虽然我们仍在执行分析，但我们还没有决定让某人担任该特定角色。

• 如果您是现有的BA，那么在转向敏捷软件开发时，您可能需要考虑以下几种策略：
• 认识到敏捷团队由推广专家而不是专家（如分析师）组成。您的分析技能很有价值，显然是一个良好的开端，但您需要能够做得更多。准备好与其他团队成员密切合作，帮助他们将技能转移给他们并从中获取新技能。
• 业务分析师，尤其是业务分析师，可以在敏捷项目中扮演利益相关者/客户/产品所有者的角色，代表整个项目中的利益相关者社区（参见图2）。它们也可能导致在迭代0期间设想工作的初始要求。
• 有关更多详细信息，请参阅文章重新思考业务分析师的角色。

协作要求
图2. BSA作为产品负责人。

六，结论

分析的性质已经改变。几十年前，分析被视为一系列项目生命周期中的转型过程。随着20世纪80年代和90年代面向对象的日益普及，分析很快被视为迭代和渐进过程的一部分，并且在新的千年中，分析的本质再次发生变化。今天，分析更好地被设想为涉及开发人员和利益相关者的高度协作，迭代和渐进的努力。>分析过程的演变需要业务系统分析员（BSA）工作方式的演变，并且在许多情况下这个角色可以说是对于推广专家的开发人员而言，这种做法有所消失。

7.致谢

我要感谢以下人员对Agile Modeling邮件列表的输入：James Bielak，Adam Geras，Ron Jeffries，Kent J. McDonald，Les Munday，Paul Oldfield，Stephen Palmer，Tom Pardee，Dave Rooney，Gabriel Tanase和Paul Tiseo。

 

原文：http://agilemodeling.com/essays/agileAnalysis.htm

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】