---
cid: 186
title: 软件开发本质论 笔记
slug: 186
date: 2019/12/14 15:53:00
updated: 2019/12/14 15:55:24
status: publish
author: harumonia
categories:
  - 桂苑酌记
tags:
  - 软件开发
noThumbInfoStyle: default
outdatedNotice: no
reprint: standard
thumbChoice: default
thumbStyle: default
hidden: false
---

[美]Ron Jeffries

## 价值

80/20 法则:每个人想要的功能特性可能都不相同,但是没有人想要所有的功能特性.

首先推出能够产生价值的功能特性.

引导团队构建不仅对我们有意义,同时对用户也有意义的特性,即, **最小可市场化功能特性**
与最小可市场化功能特性相比,在更细的粒度上提供商业方向更能使我们受益.

价值的最大化在于频繁交付小的\以价值为中心的功能特性.

<!-- more -->

### 价值是什么

简单地说,价值就是"我们想要的东西".
所以,在不同的情境下,价值的侧重不同.

### 如何衡量价值

价值的衡量具有一定的主观性,纯粹以数据衡量价值是不可取的.

1. 我们知道的并非真正的数据
2. 大的差别很重要,小的差别则并不重要
3. 不同类型的价值不具备可比性

你的想法? <==> 数据?
团队协商,达成共识?

> Ron 认为,通过数值来表示价值可能会是我们滑入深渊.因为数值往往将多个衡量指标无序地混杂在一起.
> 同时,他指出 **大多数与金钱相关的衡量指标在时间上都落后** .

_所有的衡量指标的真正作用都是帮助产品推动人\项目干系人\以及团队成员理解什么是真正的价值._

## 功能特性

传统软件开发:分析-设计-编码-测试
根据功能特性开发:更加地灵活,更加地高效

> 这有点类似于敏捷开发,不过以前跟某人交流的时候,他指出国内大部分的公司目前所谓的敏捷开发都只是有形而无实.

### 组建强大的团队

确保其团队成员知道要做什么,然后让他们自己去搞清楚怎么做

- 目的来源于具体的业务:填鸭式地直接告知解决方法,而不是通过主动思考,整个团队将需要更长的时间获得明确的目标感.
- 自主能够给整个团队带来责任感
- 专精源自迭代过程

**一言以蔽之,在自主的专精团队中,每个人都清楚团队的目的.**

> 团队成员的能力波动值太大的话,是灾难性的.

### 自然开发的管理之道

跨职能团队拥有交付软件的每一个增量版本所需的全部技术与能力,团队成员能够自己进行测试,自己编写文档,所有与软件开发直接相关的事情都可以有他们去做.越是接近这样的理想状态,所需的协作配合就越少.

五大管理要素:

- 计划
- 组织
- 人员配备
- 领导
- 控制

制定计划:
无论是长期计划还是短期计划,核心都是从高价值的功能特性到低价值的功能特性.
管理人员要随时关注计划的进展,同时,高层计划者和管理者要十分清楚项目有哪些功能特性,同时要求产品推动人通过演示实际可用的软件来展现这些功能特性.
**计划的根本目的是为了取得更好地结果.so,随时关注价值的变化,并适当地对计划进行调整**

自然软件开发的方法倡导将权力授予实际完成工作的人.

> 放权是一个很艰难的抉择,这需要建立在有足够的信任,或者自己有绝对的权利之上,即,相信他们能够做好,当然,如果最不好,我能有权利把你们开除了.缺一不可.

### 根据功能特性组织团队

没有足够多的专家? -> 组建实践社区,用现有的专家去培养专家

功能特性团队使得"规模扩展"很容易

> 很明显再就是暑假时的项目管理模式,将培训与项目结合,并行工作,不过当时的我也不是什么专家,所以组织安排大家学习的结果差强人意.也许收获最大的反而是我?

- 做计划是必要的

  - 项目的时间期限和开始预算
  - 优先开发那些最优价值的功能特性
  - 确保产品能够随时发布,并在时间结束时立刻停止

- 详细的计划是无用的
- 持续计划:分解功能特性
  - 团队应该以固定的节奏工作
    1. 这样的工作周期通常称为"迭代"或"冲刺",一般为几周
    2. 每个功能特性最好在两-三天完成
  - 承担多少工作?
    1. 每个迭代周期的工作量根据上个周期来划分
    2. **重要的不是准确地估计工作量,而是能够以一贯的节奏来完成工作**
  - 根据"挑战性的目标"制定计划,危害性很大
    1. 赶工会客整个项目带来更多的缺陷
    2. 压力具有破坏性,避免向团队施压

五卡法

> 这一点暑假就做得很不好,或者说,这是我和涛哥双核驱动模式下的一个必然的恶果.

### 根据功能特性构建产品

- 在每一个短周期内,完整地构建一个小的产品
- 细化产品愿景
- 总是将价值可能最大的任务列位下一个目标
- 确定真实的进展
- 淘汰测试再修复式的收尾方式
- 随着项目进行,进一步扩展和优化设计
  1. 设计得太多或者太少都会导致开发缓慢

**为了加快开发速度,我们能做的最有价值的事情就是提高团队成员的技能.这一投入很快就能带来以下回报:浪费在修复缺陷上的时间会更少,开发过程会更加流畅.不要将迅猛当作高效.速度最快的团队总是平稳\优雅地前进.**

#### 重构

我们需要稳步前进.为此,需要时刻爆出设计的清晰和整洁.为了做到这一点,必须进行重构.

构建一个功能特性所需的时间大致来自以下两个主要方面:

- 它本身固有的难度
- 将它加入现有代码时可能的难度

**露营地规则:在离开露营地时,要让它比你来的时候更好.**

## 价值的完整循环

- 我们最终想要的是价值,提供价值的则是功能特性.功能特性发布得越早,我们就能越早提供价值.
- 基于价值的管理比基于时间或工件等不提供价值的事物更胜一筹.
- 根据功能特性做计划很简单,只有正在必要时才进行估算.根据以往完成的工作量来安排下一阶段的工作,效果会更好.
- 采用逐渐增加功能特性的增量式开发方法,要求我们每隔几周就能够开发出小而完整的产品.所开发的产品必须总是能够正常运行,而且其设计也是良好的.
- 开发工作必须要交付真正可用的功能特性.产品必须经过严格的测试,业务人员和开发人员都需要参与其中.同时,产品还必须拥有良好的设计,而且开发人员需要保持产品的设计一直处于良好状态.

## 后记

梦里不知天在水，满船清梦压星河。