让我们一起探索如何通过频繁提供可见价值来使软件开发变得更简单。

价值的循环

enter image description here

第一章 寻找价值

价值:就是那些我们想要的东西

我们会自下而上从金字塔的底部开始。

指导:通过创建以价值为已任的团队来实现价值的创造,因此需要确保团队成员指导客户需要什么,以及客户留给我们的开发时间。我们通过观察实际构建出产品来对团队的工作进行指导。

组织:我们围绕产品的功能特性来进行组织,因为这些功能特性可以使我们更好地计划,并更快创造出价值。

计划:根据所需功能特性的前后顺序来对其进行选择,以此来控制项目的进展。这样就能够及时创造价值。

构建:通过逐个实现功能特性来构建产品。这样能够频繁地进行价值的交付,同时能够尽早、经常地看到项目的进展。

划分:将功能特征划分为小块,使每一块尽可能小,前提是它们仍然有价值。这样就能尽早地构建出有用的产品,并在交付日期到来之前对产品进行优化和提升。时刻准备交付产品。

质量:采取必要的措施,以确保生产出来的产品设计优秀、品质精良。(重构和测试是不能忘的)

第二章:价值就是我们想要的东西

只有当软件发布时,它的价值才能体现。

根据功能特性划分价值 假设每个功能特性的高度代表它的价值,宽度代表它的成本。

第三章:根据功能特性可以指导得更好

对于任何一个项目,我们首先知道的第一件事是项目的截止日期。 根据功能特性交付项目更具有可预见性。 enter image description here 上图中,红色曲线代表传统项目一直不停地进行着,但传达的信息很少,而且传到的时间也很晚;直线代表的项目却能够频繁、定期地向我们展示真正有价值的功能特性,我们也能够看到正在形成的软件! 根据功能特性交付项目能够提供更好的信息和指导,同时也会产生更好的结果。

第四章:根据功能特性组织团队

我们想通过功能特性一点一点地获得价值。当通过价值和功能特性来管理项目时,就能获得成功。 如果根据技能来组织团队,每一个项目都需要经过几个团队的合作交接才能完成。每一次交接都需要制订日程表,这样会造成进度的延迟。而且极有可能每一次交接都会产生相应的问题。

团队构建功能特性

根据最重要的功能特性优先的原则去组建团队,团队正在开发所有待完成功能特性中最重要的那个,那么很明显,它值得你去投入余下的人员中最优秀的人员。 同时为他们创造了一个锻炼和学习的机会。

第五章:根据功能特性进行计划

当我们经常性地发布软件版本时,情况会最好:价值会增长得更快、更好;管理层每隔一段时间就能够看到项目的进展;同时,由于目标小而明确,开发工作也能够以最好的方式进行。

然而,产品的“愿景”总是从伟大的想法开始,虽然朦胧却很诱人。愿景是关于产品的大的思路,而不是小的功能特性。

做计划是必要的

艾森豪威尔将军曾说过:“计划本身是无用的,但做计划是必要的”。我们的确需要针对产品认真思考,不只是开始,而是一直需要这样做。

尽早确定哪些核心的功能特性是必须尽快有,哪些功能特性不能没有,这很重要。我们要确定这两种功能特性,并将它们记录下来。

关于有多少软件项目最终支出远远超出预算。

更好的方法如下:一是确定项目的时间期限和开支预算;二是优先开发最优价值的功能特性;三是确保产品能够随时发布,并在时间结束时立即停止。开发工作甚至很有可能会在截止日期之前停止,因为我们已经得到了最重要的功能特性。

第六章:根据功能特性构建产品

根据功能特性来构建产品,能够使我们交付更多的价值。由于开发团队能够演示软件,因此无论是管理还是做计划都很容易。

enter image description here

在每一个短周期内,完整地构建一个小的产品

在计划和管理项目时,我们将其划分为多个为期一至两周的短周期。在每个周期内,确定需要完成哪些功能特性,并清除地说明如何测试它们。这样开发团队可以根据这些要求构建功能特性,由此我们也可以验证功能特性是否通过了测试。

enter image description here

细化产品愿景

这就意味着业务人员要有能力将大的、模糊的、笼统的需求切分为小的、切实可行的开发步骤。

总是将价值可能最大的任务列为下一个目标

整个团队一起合作,共同确定有能力完成且价值高、成本低的功能特性。团队就学会了怎样在有限的时间和预算内构建最好的产品。 功能特性要么“已完成”,要么“未完成”,不存在中间地带。

确定真实的进展

根据功能特性构建产品这种方法使得每一次迭代都包含完整的开发流程:从需求到设计,然后编码,最后测试。 enter image description here

淘汰测试再修复式的收尾方式

为了根据功能特性构建产品的方法能够发挥作用,在为期两周的迭代结束时,我们开发的软件必须是几乎没有缺陷的。为了确保没有缺陷,必须随时对一切进行检测。

enter image description here 随着项目的进行,进一步扩展和优化设计

通过观察开发速度的变化,也就是交付功能特性的速度变化,我们就能学到什么程度的设计恰到好处。设计得太多,进展会缓慢;设计得太少,进展同样会缓慢。我们的应对法则是:调整,观察,再调整。

第七章:同时构建功能特性与基础

enter image description here

有2种方法:一是首先完整构建出项目的基础结构,缺点是:若优先构建基础,则在交付日期到来时,可以交付的功能特性太少。它会延缓项目进度的同时减少产品的价值。二是在构建每一个完整的功能特性时也设计它的基础,缺点是:如果逐一构建完整的功能特性,当交付日期到来时,产品很有可能会缺少关键的功能特性。

首先构建简单而实用的版本

最好的方法是我们以最快的速度构建出最小可行产品。这需要我们判断用户需要什么以及我们还剩下多少时间。在多次迭代中逐渐完善每个功能特性。为在交付日期到来时获得尽可能好的结果而努力。

第八章:零缺陷与良好的设计

为了确保产品在任何时候都拥有良好的设计而且没有缺陷,我们需要有良好的技术实践方法。实时上,因为功能特性是逐渐增加和完善的,同时其设计也是逐渐改进的,所以出现错误在所难免。我们需要进行持续的、全面的测试。

我们需要进行2个层面的测试:“业务”测试和“开发人员”测试。

在每一次迭代结束时,都需要进行业务层面的测试来验证是否得到了想要的软件。这就是人们常说的“验收测试驱动开发(ATDD)”。 在已知的最好方法就是先写测试代码,然后再运行这些代码。这通常被称为“测试驱动开发(TDD)”。

重构和测试是我们时刻保持设计良好的2个法则。

第九章:价值的完整循环

(1)我们最终想要的是价值,提供价值的则是功能特性。功能特性发布的越早,我们就能越早提供价值。
(2)基于价值的管理比基于时间或工件等不提供价值的事物更胜一筹。
(3)根据功能特性做计划很简单,只有在必要时才进行估算。根据以往完成的工作量来安排一下阶段的工作,效果会更好。
(4)采用逐渐增加功能特性的增量式开发方法,要去我们每隔几周就能够开发出小而完整的产品。
(5)开发工作必须要交付真正可用的功能特性。产品必须经严格的测试,业务人员和开发人员都需要参与其中。