敏捷软件开发实践 估算与计划 epub pdf mobi txt 电子书 下载 2024

敏捷软件开发实践 估算与计划 epub pdf mobi txt 电子书 下载 2024

敏捷软件开发实践 估算与计划 epub pdf mobi txt 电子书 下载 2024

产品特色

内容简介

　　详述用于估算和计划任何敏捷项目的行之有效的技巧
　　《敏捷软件开发实践 估算与计划 为对敏捷项目进行估算和计划提供了紧贴实用的**指导方针。在本书中，敏捷联盟联合创始人Mike Cohn讨论了敏捷估算与计划背后的哲学思想，并通过列举现实世界的例子和项目案例具体展示了如何完成工作。本书绝对是你开发工具箱中必不可少的敏捷估算“利器”。
　　本书清晰地阐述了相关概念，并引导读者逐步找到下列问题的答案：将构建什么产品？产品规模多大？需要在何时完成？到那时我们到底能完成多少？你*先会认识到优秀的计划由哪些要素组成，接着会了解到如何才能使计划敏捷化。
　　采用本书中讲述的方法，你将获得敏捷估算工具，帮助你从始至终保持敏捷、节省时间、充分利用资源并且完成更多工作。本书要点如下：
　　为什么传统的指令性计划会失败而敏捷计划会取得成功
　　如何使用故事点和理想人天来预估特性的规模，以及它们分别适用于哪种情形
　　重设估算的方式和时机
　　如何同时采用财务及非财务手段来确定特性的优先级
　　如何将大的特性分解为更小的、更便于管理的特性
　　如何计划迭代周期并对团队的初始进度进行预估
　　如何安排具有高度不确定性或进度相关风险的项目的进度
　　如何对由多个团队合作开发的项目进行估算
　　本书介绍所有敏捷、半敏捷或者迭代流程，包括Scrum、XP、特性驱动的开发、水晶方法、自适应软件开发、DSDM、统一过程(UP)以及其他许多方式。它无疑是每位研发经理、团队经理和成
　　员不可或缺的宝贵资源。

作者简介

　　Mike Cohn，是专注于流程与项目管理的咨询与培训公司Mountain Goat Software的创始人。Mike拥有逾20年的行业经验，担任过创业公司乃至财富40强企业的技术负责人，他还是敏捷联盟的发起成员之一，经常在业界相关杂志上发表文章并出席有关会议。他也是User Stories Applied (Addison-Wesley ，2004年出版)一书的作者。

精彩书评

　　“你的项目进展顺利吗？对需求变更感到沮丧？前途未卜？产品质量不佳，又延误了截止期限？Mike Cohn*富洞察力，他清晰明了地展示了如何有效地开发具有卓越业务价值的软件。通过阅读本书，你可将精力专注于真正关键的行动，当环境条件变化时也将继续如此。”
　　——Rick Mugridge，Rimu Research有限公司总监，Fit for Developing Software 的*一作者

　　“我们是本书所述敏捷方法的忠实信徒，通过实践和持续采用这些方法，获得了许多*其重要的积*影响。我强烈向有志于使软件开发更可行、更有效的所有读者推*此书。”
　　——Mark M. Gutrich，Fast 401k公司总裁兼*席执行官

目录

第Ⅰ部分 问题与目标
第1章 计划的目的 3
1.1 为何要进行估算和计划 4
1.1.1 减少风险 5
1.1.2 降低不确定性 5
1.1.3 提供更好的决策支持 5
1.1.4 建立信任 6
1.1.5 传递信息 6
1.2 优秀的计划是什么 7
1.3 敏捷计划是什么 7
1.4 小结 8
1.5 讨论题 8
第2章 计划失败的原因 9
2.1 基于活动而不是基于特性进行计划 9
2.1.1 活动不会提前完成 10
2.1.2 延误沿着计划表向下传递 10
2.1.3 活动不是互相独立的 11
2.2 多任务处理导致更多的延迟 12
2.3 不按优先级开发特性 13
2.4 忽视了不确定性 13
2.5 把估算当作承诺 14
2.6 小结 14
2.7 讨论题 15
第3章 敏捷方法 17
3.1 项目的敏捷开发方法 18
3.1.1 敏捷团队作为一个整体工作 18
3.1.2 敏捷团队按短迭代周期工作 19
3.1.3 敏捷团队每次迭代交付一些成果 19
3.1.4 敏捷团队关注业务优先级 20
3.1.5 敏捷团队进行检查和调整 21
3.2 敏捷计划方法 21
3.2.1 计划的不同层次 22
3.2.2 满意条件 23
3.3 小结 25
3.4 讨论题 25
第Ⅱ部分 估 算 大 小
第4章 使用故事点估算大小 29
4.1 故事点是相对的 29
4.2 速度 31
4.3 小结 33
4.4 讨论题 33
第5章 使用理想人天进行估算 35
5.1 理想时间和软件开发 36
5.2 以理想人天作为对大小的度量 37
5.3 给出一个而不是多个估算值 37
5.4 小结 38
5.5 讨论题 38
第6章 估算方法 39
第7章 重估 49
第8章 在故事点和理想人天之间进行选择 55
第Ⅲ部分 为价值制定计划
第9章 确定主题的优先级 63
第10章 确定经济优先级 71
第11章 确定渴望度优先级 85
第12章 分解用户故事 93
第Ⅳ部分 进 度 计 划
第13章 发布计划精粹 103
第14章 迭代计划 111
第15章 选择迭代长度 127
第16章 估算速度 135
第17章 不确定性缓冲计划 143
第18章 计划多团队项目 155
第Ⅴ部分 跟踪与交流
第19章 监督发布计划 165
第20章 监督迭代计划 173
第21章 关于计划的沟通 179
第Ⅵ部分 敏捷计划有效的原因
第22章 敏捷计划有效的原因 189
第Ⅶ部分 案 例 分 析
第23章 案例分析：Bomb Shelter Studio 197

精彩书摘

在故事点和理想人天之间进行选择

——采用故事点进行估算

“If you tell people where to go，but not how to get there，you’ll be amazed at the

results.”

—— Ceneral George S.Patton

有利于故事点的考虑因素

● 故事点有助于驱动跨功能的行为

● 故事点估算不会过期

● 故事点是纯粹对大小的度量

● 故事点估算通常更快

● 我的理想人天不等于你的理想人天

1.故事点有助于驱动跨功能的行为

敏捷团队之所以会成功，一个原因在于这种团队是跨功能的。也就是说，敏捷团队包含了来自构建产品所需所有角色的成员，包括程序员、测试人员、产品经理、可用性设计师、分析师、数据库工程师等。当我们首次建立一个跨功能的团队时，有些成员往往可能很难放下他们的部门身份。而项目参与者需要首先把自己看成团队成员，然后才是专业贡献者时，产品这样才能从中受益—— 也就是说，“我在进行Napa 项目，是一名测试人员”，而不是“我是一名测试人员，分配到了Napa 项目中”。两者的区别似乎微不足道，但在思维方式上的改变则并非如此微小。

用故事点进行估算可以帮助团队学会跨功能工作。由于一个故事点估算应该是代表整个团队所有工作的单一数值，因此对故事点的估算可以开启针对所涉及到的全部相关事情的高层次讨论。另一方面，对理想人天的估算经常涉及专业小组估算用户故事中“他们的那部分”需要多少时间，然后把所有的这些原子估算累加在一起。例如，程序员可能认为需要3 个理想人天，数据库工程师认为需要1 天，而测试人员需要2 天。该故事就会分配6 个理想人天。

最早针对用户故事的讨论应该如何进行，在这一问题上的微小差异会对这个故事的开发方式产生持续影响。

2.故事点估算不会过期

以故事点方式进行的估算比以理想日进行的估算具有更长的“保质期”。因为团队对技术、业务领域和他们自己的经验不同，以及其他的一些因素，都会导致以理想人天进行的估算发生变化。想要了解原因，假设一名程序员正在学习一门新语言，他被问及需要多少时间来开发一个小程序。他的答案可能会是5 天。过几个月后，再问这个程序员开发一个完全相同大小和复杂度的程序需要多少时间。由于他对这门语言更为熟悉，他的答案可能会是1 天。现在我们就遇到了问题，两个程序的大小完全一样，但对它们的估算值不一样。

我们希望经过一段时间，对速度的测量会纠正或者解决这个问题。但在这个例子中是行不通的。相反，虽然完成了更多的工作，我们仍会看到一个稳定的速度。假设这名程序员是开发小组中的唯一人员，他采用一周的迭代周期。他第一次开发这个程序的时候，会估算需要5 个理想日。我们假设在他所处的开发环境中，一天就相当于一个理想人天。他在迭代的第一天开始这个项目，在第五天结束。他在这次迭代中的速是5。几个月以后，因为他把一个相似的程序估算为1 个理想人天，他将在一次迭代中完成5 个这样的程序。他的速度还是5，虽然做的工作以前的5 倍。对某些项目，尤其是那些采用了新技术，或者团队对应用领域并不熟悉的项目，这种现象会非常明显。

需要注意，如果由于架构的开发导致工作的大小发生了变化，故事点估算和理想人天

估算都应该更新。但是，如果只是因为团队对某些东西更为熟悉，则只需修改理想人天

估算。

3 故事点是对大小的纯粹度量

正如本章的引言部分所描述，当估算一件事需要多久时，重要的第一步是估算它的大小或者说需要做多少事情。故事点纯粹是对大小的估算，而理想人天不是。理想人天可以被用作对大小的度量，但是存在一些不足。前一节中曾经强调，以理想人天做出的估算会因为开发人员熟练程度的变化而改变。故事点不会出现这个问题—— 大小就是那么大，不会发生变化。这种不变性是任何对大小的度量都希望得到的特性。

故事点对大小的纯粹度量带来了两个好处。首先，这意味着我们可以只通过类比就进行估算。有一些可靠的证据表明我们更善于估算“这个和那个差不多”而不是估算事物的绝对大小(Lederer and Prasad 1998；Vicinanza 1991)。另一方面，当我们采用理想人天时，也可以用类比进行估算。但使用理想人天进行估算时，我们也倾向于考虑日程表以及用户故事需要多长的开发时间。

其次，由于故事点是对大小的纯粹度量，完全是抽象的，因此不会受到把它们与现实进行比较的诱惑。而用理想人天进行估算的开发小组几乎不可避免地会把他们的理想人天与现实人天进行比较。然后他们会发现要找出理由说明自己为什么在一次10 天的迭代中“只”完成了8 个理想人天的工作。

4 故事点估算通常更快

用故事点进行估算的团队看起来会比用理想人天进行估算的团队进行得更快。在估算很多用户故事的时候，都需要对故事进行高层次的设计讨论：我们要在数据库中实现它吗？可以重用用户界面吗？这对中间层有什么影响？所有这些问题都会在某个时候涌现出来。

我的经验是用理想人天进行估算的团队有一种倾向，他们对这些问题的讨论会比用故事点进行估算的团队更深入一些。这个差异只是推测出来的，因为用理想人天进行估算的时候，更容易会考虑开发一个用户故事所需完成的各项任务，而不是从这个故事相对其他故事的大小这个角度来考虑。

5 我的理想人天不等于你的理想人天

假设有两个跑步者，一个跑得快一个跑得慢，他们一起站在一条小路的起点。两人都可以看到小路的全程，而且都认为它有1 公里长。他们可以把它与另一条他们都跑过的路进行比较，而且都认为它大约是那条路的一半长度。这种对道路尺寸(实际上在这个例子中是距离长度)的讨论是很有意义的。

假设两个跑步者讨论的是跑这些路所需要的时间而不是讨论它们的长度。跑得快的人会说：“这是一条5 分钟的路。”跑得慢的人的回答会是：“不对，这条路至少是8 分钟。”两个人当然都是对的，但他们没办法解决这个差异，除非同意按照其中一个人跑完这条路需要的时间(或者另一个人需要的)来讨论。

使用理想人天时会出现同样的问题。你可能会认为你可以在3 个理想人天内完全开发一个特定的用户故事。我认为我可以在5 天内完成。我们可能都是对的但如何达成一致？如果我们认为你将是完成这项工作的人，我们也许会选择使用你的估算。但是这也许会是一个错误，因为等到我们实际上处理这项工作的时候，你可能太忙了，因此需要我来完成它，而我就会推迟完成，因为对它的估算值是你所需要的3 天，但是我实际上需要5 天。大多数团队的做法是忽略这个问题。如果所有开发人员的水平大致相当或者程序员总是结对工作(in pair)，就可以抵消生产效率上的极端差异，忽略这个问题的做法就是可以接受的。

前言/序言

　　本书本来被命名为《估算与计划敏捷项目》。不过，书名最终确定为《敏捷软件开发实践 估算与计划》。两者的差异似乎微不足道，但实际上并非如此。现在的书名明确了估算和计划过程本身就应该是敏捷的。不采用敏捷估算和计划，项目就不可能是敏捷的。
　　本书的大部分内容是关于计划，我把它看作是用来回答“我们要构建什么以及何时完成？”这一问题。但是，要回答关于计划的问题，我们还必须解决关于估算(“它的规模有多大？”)和进度安排(“什么时候能完成？”和“我到那时能得到多少？”)的问题。
　　本书由7个部分共23章组成。每一章的结尾都有对该章重点的小结和一组讨论题。由于估算和计划应该是整个团队的工作，因此我希望对本书的阅读方式是团队成员每周聚在一起，对看过的内容以及每章结尾的讨论题进行讨论。由于敏捷软件开发在全世界都受到欢迎，因此尽可能避免让本书显得过分以美国为中心。为了达到这一目的，我使用了一种通用的货币单位，将金额写作500“币”，而不是500美元或者500欧元。
　　本书的第I部分介绍了计划为什么重要、我们常会遇到的问题，以及敏捷方法的目标。第1章是本书的起始，介绍了计划的目的、一个优秀的计划由哪些部分组成，以及什么才是敏捷计划。第2章中介绍了为什么传统估算和计划方法是导致结果难以令人满意的最重要原因。最后，第3章首先简要地重述了敏捷的含义，然后概括介绍了本书其他部分在不同层次上所采取的敏捷估算和计划方法。
　　本书的第II部分介绍了估算的一个主要原则，即对大小和时间长度的估算应该相互独立。第4和第5章介绍了两个适用于对要开发的特性大小进行估算的计算单位：故事点和理想人天。第6章讲述了采用故事点和理想人天进行估算的技巧，并包括了对计划扑克的介绍。第7章讲述了何时以及如何进行重新估算。第8章则提供了有关如何在故事点和理想人天之间进行选择的建议。
　　第III部分“为价值进行计划”提供的建议告诉项目团队如何确认他们正在构建尽可能好的产品。第9章介绍了在确定特性的优先级时需要综合考虑的一些因素。第10章展示了对特性或特性集合的财务回报进行建模的一种方法，以及如何对财务回报进行比较以便开发团队首先处理最具价值的特性。第11章主要讲述有关如何评估产品用户对各个特性的需求程度并确定其优先级的建议。第12章对本部分进行总结，给出了一些建议，帮助将大的特性分解成更小的、更易管理的特性。
　　在第IV部分中，我们将注意力转移到了有关项目时间进度安排的方面。第13章首先讨论了对一个相对简单的、单一开发团队的项目安排进度表时所涉及的步骤。第14章讨论了如何制定迭代的计划。第15章和第16章讨论了如何选择合适的迭代周期长度以及如何估算开发团队的初始速率。第17章详述了如何安排一个具有很高不确定性的或是在时间进度上很可能出错的项目的进度表。第18章是这一部分的结尾，讲述了对由多个团队共同开发的项目进行估算和计划所必需的其他步骤。
　　一旦建立了计划，团队就必须和整个公司的其他部门进行交流，并根据计划进度对开发团队的进度进行监督。这是第V部分的3章的主要内容。第19章主要关注对发布计划进行监督，而第20章关注对迭代计划进行监督。这一部分的最后一章，第21章主要解决如何就计划及其进度进行沟通。
　　第22章是第VI部分唯一的一章。这一章与第2章讲述的“为什么传

敏捷软件开发实践 估算与计划 epub pdf mobi txt 电子书 下载 2024

看别人推荐买的，有时间好好看看

速度快的没得说，昨天晚上下单我大西安仓库速速发货!

人月神话 + 人件。两本书一起买了！

书已经看完了，却是改变了我编程的不少思路，人月神话，真是一本好书啊

个人觉得介绍有点言过其实了，可以当做小说看，但软件工程还得弄本权威的教材看看

帮别人买的，计算机系列经典图书。

设计，设计，再设计。

书有点老了，但的确算经典。就讲每个月每月干一个项目这事。人月其实就是人/月，。

还没开封，最近自己对敏捷开发非常感兴趣，要好好学习一下