标签：
让客户做决定
开发者及项目经理能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。
当你和客户讨论问题的时候，准备好几种可选择的方案。从业务的角度介绍每种方案的优缺点，以及潜在的成本和利益，
并和他们讨论每个选择对时间和预算的影响，以及如何权衡，记录客户做出的决定，并注明原因。
让设计指导而不是操纵开发
好的设计是一张地图，它也会进化。设计指引你向正确的方向前进，她不是殖民地，它不应该表示具体的路线，你不要被设计操纵。
CRC卡片的设计方法
类名：。
职责：它应该做什么？
协作者：要完成工作他要与其他什么对象一起工作？
合理地使用技术
根据需要选择技术 首先决定什么是你需要的，接着为这些具体的问题评估使用技术，对任何要使用的技术，多问一些挑剔的问题，并真实地做出回答。
引入新技术时候考虑：
这个技术框架真能解决这个问题吗？
你将会被它拴住吗？
维护成本是多少？
保持可以发布，提早集成，频繁集成。
主要讲的是版本控制问题，公司分一条master分支用于不断迭代开发而develop分支用于版本发布
但发现一些紧急的bug直接在发布版本分支修改，然后再master修改
一些版本升级的需求则是基于master建立问题分支，后集成
代码集成是主要的风险来源。想要规避这个风险，只有提早集成，持续而有规律地进行集成，
集成拖得太晚，可能由于分支之前各样的依赖关系，会导致集成顺序造成集成失败，
提早实现自动化部署
一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要测试应用一样测试部署。
这些工作都应该是无形的。系统的安装或者部署应该简单、可靠及可重复。一切都很自然。
使用演示获得频繁反馈
清晰可见的开发。在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一周或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
跟踪问题很多反馈--修正、建议、变更要求、功能增强、bug修复等，要注意的信息很多，建议有个一跟踪系统记录这些日志，或使用excel上传到git。
使用短迭代，增量发布
增量发布，发布带有最小却可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。短迭代让人感觉非常专注且具效率。你能看到一个实际并且确切的目标。严格的最终期限迫使你做出一些艰难的决策，没有遗留下长期悬而未决的问题。
固定的价格就意味着背叛承诺
让客团队和客户一起，真实地在当前项目中工作，做具体实际的评估，由客户控制他们要的功能和预算。
如何估算项目花费以及时间又是另一门学问了
1.提议想构建系统demo（做出最主要功能部分），完成第一次交付应该不多于6~8周，向客户解释，让用户真正使用
2.客户可以选择一系列新的功能，或者可以取消合同，仅需字符第一个迭代的几周费用
3.接下来的迭代就比较好控制了
高效程序员的45个习惯 敏捷开发修炼之道 读书笔记 第四章 交付用户想要的软件
标签：
原文地址：http://www.cnblogs.com/linkarl/p/5729441.html
