《超越需求：敏捷思维模式下的分析》—第1章 1.10节切记

第2章 有用的概念 超越需求:敏捷思维模式下的分析2.1 简介 本章将对书中其余章节介绍的方法和技术的背后概念进行说明.这些概念与我们如何思考分析的分类方法有关: 需要和解决方案: 结果和产出: 发现和交付. 通过介绍这些概念,希望为本书其他章节创建一个共同语言.这些概念所使用的术语也罗列在术语表中.

第一部分 理念 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接. 第1章 指导原则超越需求:敏捷思维模式下的分析1.1 简介敏捷方法对我最大的影响也许正是这样一种理念,即团队做事方法应基于价值观和原则而不是基于实践.实践往往对情境非常敏感--用于Web应用程序的实践与用于商业佣金系统的实践不同,而用于商业佣金系统的实践与用于大型机的工资系统的实践也不同.在这3种情况下采用同样的实践就是制造麻烦.而价值观和原则往往更广泛适用."敏捷软件开发宣言&q

版权超越需求:敏捷思维模式下的分析• 著 [美] Kent J. McDonald 译 霍金健 责任编辑 杨海玲 • 人民邮电出版社出版发行 北京市丰台区成寿寺路11号 邮编 100164 电子邮件 315@ptpress.com.cn 网址 http://www.ptpress.com.cn • 读者服务热线:(010)81055410 反盗版热线:(010)81055315 内容提要超越需求:敏捷思维模式下的分析项目成败的关键在于是否在"做正确的事情",而本书正是从分析的角度帮助项

2.2 需要和解决方案在前言中,对分析涉及的活动进行了介绍: 理解利益相关者: 理解情境: 理解需要: 理解解决方案: 组织并持久保存解决方案信息. 对我而言,一些关键定义是按顺序来的.为此,参考<Guide to the Business Analysis Body of Knowledge Version 3>(BABOK v3)一书中介绍的业务分析核心概念模型(Business Analysis Core Concept Model,BACCM),其中定义了6个核心概念,如表2-1所述.

2.4 发现和交付 第三种对分析分类的方法根据我们何时进行分析来分类.划分活动常常很有用,这可能是人们喜欢基于计划的方法所描述的各种阶段(分析.设计.开发和测试)的原因之一.将知识工作分解为不同活动有一定优势,因为没有哪一个人能擅长知识工作的每个方面,所以把活动分为不同的类别显然有助于把事情分解为可管理的工作,并把焦点集中于不同的方面. 但组织这些工作的最好方式是什么呢?当人们引用Winston Royce被视为瀑布计划之源头的论文(www.serena.com/docs/agile/paper

1.3 合作合作(collaboration)有两个方面的含义.一个方面是团队成员尽可能高效协同工作的能力.这方面可能是在所有项目中--实际上在所有团队工作中--都具有的,这方面总能得到提升.实际操作中,这意味着从团队环境中移除所有阻止有效沟通的障碍,并且有团队成员可以高效地引导(facilitate)团队合作. 合作的另一个微妙但同样重要的方面是,实际上完成项目核心工作的团队成员也是做计划并报告进度的人.这是从项目的传统视角看到的转变,传统项目中这些类型的任务由项目负责人完成.团队成员是最熟悉

1.2 交付价值价值很难界定.在很多方面,这就像美和质量一样:"当我看到它的时候就会知道它."对一个人很有价值.很重要,但对其他人也许一点儿也不重要.和其他很多事情一样,交付价值也是和具体情境非常相关的.对我而言,评估价值就像试图理解它是否是值得的,而这里的"它"可能指的是承担或继续一项自发行动或交付一个具体的特性. 当你所交付的(产出)满足了利益相关者的需求(提供了预期的结果)时,你的团队就是在交付价值(deliver value).交付价值也为项目(projec

1.5 简化敏捷宣言背后的一条原则是"最大化未完成工作的数量".这意味着想要交付最少的产出(output)并使其结果(outcome)最大化(正如在1.2节所介绍的),并且只使用绝对必要的流程.我在1.2节中讨论过交付正确的工作,这里我想讨论一下如何简化交付正确工作的方法. 简化意味着团队一开始就应该采用一种刚好够用(barely sufficient)的方法.当团队启动一个新项目时,应该首先确定对项目成功绝对必要的活动,然后就只做这些活动.在项目进行的过程中,经过一些反思,你可能意识

1.8 反思与适应团队应当不断地从经验中学习,以改进所使用的方法和项目的结果.项目常常持续超过几个月的时间.在这段时间内,业务状况.团队成员对项目目的的理解和该项目的周围环境都会增长和变化.团队应该寻求利用这种变化的优势,以确保在结果交付时项目的结果符合利益相关者的需要,而不仅仅是符合项目启动时利益相关者所理解的需要. 项目团队一直在做事后分析或经验学习,团队成员在项目结束时聚在一起讨论所发生的事情--通常是消极的方面--寄希望于他们能够记住,以便下次能做得更好.如果这种方法被认为是一个良好的实