《超越需求:敏捷思维模式下的分析》—第2章 2.4节发现和交付

2.4 发现和交付
第三种对分析分类的方法根据我们何时进行分析来分类。划分活动常常很有用,这可能是人们喜欢基于计划的方法所描述的各种阶段(分析、设计、开发和测试)的原因之一。将知识工作分解为不同活动有一定优势,因为没有哪一个人能擅长知识工作的每个方面,所以把活动分为不同的类别显然有助于把事情分解为可管理的工作,并把焦点集中于不同的方面。

但组织这些工作的最好方式是什么呢?当人们引用Winston Royce被视为瀑布计划之源头的论文(www.serena.com/docs/agile/papers/Managing-The-Development- of-Large-Software-Systems.pdf)时,通常直接聚焦到展示了几个不同阶段的图上,而这几个阶段是在创建大型系统时会发生的。但在第一页有一个很有意思且常被忽略的图,它只包含两个框,即“分析”和“编码”,并带有下面一段说明:

在所有计算机程序开发中,无论大小和复杂度如何,有两个基本步骤是一样的。如图1所示,首先是分析步骤,然后是编码步骤。如果工作量足够小并且最终产品由建造者进行操作,那这种非常简单的实现概念实际上就是所需要的全部工作——内部使用的计算机程序通常就是这样。这种开发工作也是大多数客户愿意付钱的,因为这两个步骤涉及真正的创造性工作,对最终产品的有用性产生直接贡献。
Royce继续说到这种方法完全不适合大型软件开发项目,并揭示了他对如何看待软件开发团队的一些哲学:

制造大型软件系统的实施计划如果只有这些关键步骤,注定将失败。很多额外的开发步骤是需要的,但没有步骤像分析和编码步骤一样直接贡献于最终产品,而且还推升了开发成本。客户通常不愿意为此付钱,开发人员也不愿意实施这些步骤。管理的首要职责就是把这些概念推销给这两组人,并在开发人员方面执行合规检查。
虽然我不同意这段话中的所有观点,但我发现Royce专注于分析和编码作为客户价值的两个活动很有意思。我一直在寻找一些简单直接的方式描述IT项目中的关键活动,根据经验,我倾向于把它分为“找出正确的事物来创建”和“正确地创建事物”。

Ellen Gottesdiener和Mary Gorman在他们2012年出版的《Discover to Deliver》一书中找到了合适的词语来传播这些概念。那就是:发现和交付。这两个词不仅具有头韵,而且两位作者进一步用一个无限符号包起来这两个词以表示这两个活动如何交互并彼此影响,从而进一步巩固了这些概念。终于有人听到了这些概念,Royce一定很欣慰。

这里是Gottesdiener和Gorman对发现和交付的定义,我将在本书中继续使用这样的定义。

发现:探索、评估并为潜在交付确认产品选项的工作。

交付:把一个或多个已选择的候选解决方案转化为产品可发布的部分或产品版本的工作。
这个概念最有用的方面是有一个标签与不同类型的活动关联。过去团队已经从交付角度跟踪进展,但经常没有可视化发现活动。跟踪寻找正确事物的进展和跟踪构建解决方案的进展一样有用,因而我常常将发现看板和交付看板分开,这将在第15章详细介绍。

知识工作的方方面面都涉及发现的因素。当我们在创建、测试并部署解决方案时,仍然在“发现”关于需要和解决方案的知识。区分这两个活动以强化每个活动的焦点是有益的。发现会增加针对需要和解决方案的理解,以便交付。交付主要是关于创建、测试和部署产出,而这些活动有助于进一步理解需要和解决方案,这反过来影响你的发现。当然,发现在交付过程中仍会发生,但主要工作是创建事物以帮助增进理解。

那么设计在哪里呢,为什么没有被称为一个单独的活动?一些设计发生在发现活动中,而一些设计发生在交付活动中。发现活动中的设计通过使用设计思维(design thinking)技术获得对用户更好的理解,通过模型、实例和验收条件(将在第14章介绍)描述解决方案。BABOK v3区分了需求和设计,如表2-5所示,然后说到:“需求和设计之间的区别并不总是那么清晰。同样的技术被用来需求获取、建模和分析这两者。需求会产生设计,这反过来可能推动发现并分析更多需求。两者间重点的转换往往是微妙的。”

团队基于技术选型和架构限制,在搞清楚如何在技术上实现用户故事的过程中,设计就会发生。团队针对设计展开初步讨论,但随着经验增加会修改对设计的理解,这一过程中设计活动与开发和测试交织在一起。

因此,把设计作为一个单独活动不会对整个流程增加任何价值,并且还会导致毫无意义的争论——一个活动条目是在发现活动、设计活动还是交付活动中,然而在发现(准备进行迭代)和交付(迭代交付)之间明确的划分会得到更加清晰的界限。

时间: 2017-05-02

《超越需求:敏捷思维模式下的分析》—第2章 2.4节发现和交付的相关文章

《超越需求:敏捷思维模式下的分析》—第2章 2.1节简介

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

《超越需求:敏捷思维模式下的分析》—第1章 1.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.2节需要和解决方案

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

《超越需求:敏捷思维模式下的分析》—第1章 1.2节交付价值

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

《超越需求:敏捷思维模式下的分析》—第1章 1.3节合作

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

《超越需求:敏捷思维模式下的分析》—第1章 1.5节简化

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

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

1.10 切记当你以最少的产出让结果最大化时,就是在交付价值.团队应当持续探索共同合作的方法来交付价值.缩短反馈环以鼓励持续学习.不要做对交付价值不是绝对必要的事情.具体问题具体分析.有目的地做出决策.从过去学习以改进未来.[1] 通常的流程为"请求-数据加载-模型评估-风险决策-返回结果".--译者注 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接.

《超越需求:敏捷思维模式下的分析》—第1章 1.8节反思与适应

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