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

让客户做决定

开发者及项目经理能做的一个最重要的决定就是:判断哪些是自己决定不了的,应该让企业主做决定。

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

并和他们讨论每个选择对时间和预算的影响,以及如何权衡,记录客户做出的决定,并注明原因。

 

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

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

CRC卡片的设计方法

类名:。

职责:它应该做什么?

协作者:要完成工作他要与其他什么对象一起工作?

 

合理地使用技术

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

引入新技术时候考虑:

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

你将会被它拴住吗?

维护成本是多少?

 

保持可以发布,提早集成,频繁集成。

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

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

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

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

集成拖得太晚,可能由于分支之前各样的依赖关系,会导致集成顺序造成集成失败,

 

提早实现自动化部署

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

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

 

使用演示获得频繁反馈

清晰可见的开发。在开发的时候,要保持应用可见(而且客户心中也要了解)。每隔一周或者两周,邀请所有的客户,给他们演示最新完成的功能,积极获得他们的反馈。

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

 

使用短迭代,增量发布

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

 

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

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

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

1.提议想构建系统demo(做出最主要功能部分),完成第一次交付应该不多于6~8周,向客户解释,让用户真正使用

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

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

 

posted @ 2016-08-10 11:52  郁闷紫番薯  阅读(86)  评论(0编辑  收藏