高效程序员的45个习惯 敏捷开发修炼之道 读书笔记 第四章 交付用户想要的软件

让客户作决定

开发者及项目经理能作的一个最重要的决定就是：判断哪些是本身决定不了的，应该让企业主作决定。

当你和客户讨论问题的时候，准备好几种可选择的方案。从业务的角度介绍每种方案的优缺点，以及潜在的成本和利益，

并和他们讨论每一个选择对时间和预算的影响，以及如何权衡，记录客户作出的决定，并注明缘由。

 

让设计指导而不是操纵开发

好的设计是一张地图，它也会进化。设计指引你向正确的方向前进，她不是殖民地，它不该该表示具体的路线，你不要被设计操纵。

CRC卡片的设计方法

类名：。

职责：它应该作什么？

协做者：要完成工做他要与其余什么对象一块儿工做？

 

合理地使用技术

根据须要选择技术 首先决定什么是你须要的，接着为这些具体的问题评估使用技术，对任何要使用的技术，多问一些挑剔的问题，并真实地作出回答。

引入新技术时候考虑：

这个技术框架真能解决这个问题吗？

你将会被它拴住吗？

维护成本是多少？

 

保持能够发布，提前集成，频繁集成。

主要讲的是版本控制问题，公司分一条master分支用于不断迭代开发而develop分支用于版本发布

但发现一些紧急的bug直接在发布版本分支修改，而后再master修改

一些版本升级的需求则是基于master创建问题分支，后集成

代码集成是主要的风险来源。想要规避这个风险，只有提前集成，持续而有规律地进行集成，

集成拖得太晚，可能因为分支以前各样的依赖关系，会致使集成顺序形成集成失败，

 

提前实现自动化部署

一开始就实现自动化部署应用。使用部署系统安装你的应用，在不一样的机器上用不一样的配置文件测试依赖的问题。质量保证人员要测试应用同样测试部署。

这些工做都应该是无形的。系统的安装或者部署应该简单、可靠及可重复。一切都很天然。

 

使用演示得到频繁反馈

清晰可见的开发。在开发的时候，要保持应用可见（并且客户心中也要了解）。每隔一周或者两周，邀请全部的客户，给他们演示最新完成的功能，积极得到他们的反馈。

跟踪问题不少反馈--修正、建议、变动要求、功能加强、bug修复等，要注意的信息不少，建议有个一跟踪系统记录这些日志，或使用excel上传到git。

 

使用短迭代，增量发布

增量发布，发布带有最小却可用功能块的产品。每一个增量开发中，使用1~4周左右迭代周期。短迭代让人感受很是专一且具效率。你能看到一个实际而且确切的目标。严格的最终期限迫使你作出一些艰难的决策，没有遗留下长期悬而未决的问题。

 

固定的价格就意味着背叛承诺

让客团队和客户一块儿，真实地在当前项目中工做，作具体实际的评估，由客户控制他们要的功能和预算。

如何估算项目花费以及时间又是另外一门学问了

1.提议想构建系统demo（作出最主要功能部分），完成第一次交付应该很少于6~8周，向客户解释，让用户真正使用

2.客户能够选择一系列新的功能，或者能够取消合同，仅需字符第一个迭代的几周费用

3.接下来的迭代就比较好控制了