该博客已经停止更新,新博客点击此处:DevWiki的博客
交付用户想要的软件
让用户做决定
在设计方面,做决定的时候必须有开发者参与.
在一个项目中,开发者不应该做所有的决定,特别是业务方面的决定.
决定什么不该决定.
让客户做决定.开发者,经理或者业务分析师不应该做业务方面的决定.
业务应用需要开发者和业务负责人互相配合来开发.
平衡的艺术
记录客户做出的决定.
不要用过于具体和没有价值的问题打扰繁忙的业务人员.
不要假设具体的问题不会影响业务人员的业务.
如果业务负责人回答”我不知道”,这也是一个称心如意的答案.
让设计指导而不是操纵开发
设计是软件开发过程不可缺少的步骤.
开发之前画关键工作图是必不可少的,在做设计时你需要花时间去考虑各种不同选择的缺陷和溢出,以及如何权衡.然后下一步才考虑开始编码.
严格的需求-设计-代码-测试开发流程源于理想化的瀑布式开发方法,它导致在前面进行了过度的设计.
设计可以分为两层:战略和战术.
1. 前期的设计属于战略,通常只有在么有深入理解需求的时候需要这样设计.
2. 战术设计重点是集中在单个的方法或数据类型上.这时更合适讨论如何设计类的职责.
CRC(类-职责-协作)卡片的设计方法就是用来做这个事情的.
* 类名
* 职责:它应该做什么?
* 协作者:要完成工作它需要与其他的什么对象一起工作?
什么是好的设计?
如果需求有了小变化,它仍能容易去实现,那么它就是好的设计.
好的设计应该是正确的而不是精确的.
平衡的艺术
- 不要在前期做大量的设计,并不是说不要设计.
- 计时初始的设计到后期不在管用,你仍需设计.
- 白板,草图,便利贴都是非常好的设计工具.
合理地使用技术
根据需要选择技术.
在考虑使用新技术之前,先要把你需要解决的问题找出来.找到了需要解决的问题,接下来就要考虑:
1. 这个技术框架真能解决这个问题吗?
2. 你将会被他拴住吗?
3. 维护成本是多少?
不要开发你能容易下载到的东西
写的代码越少,需要维护的东西就越少!
新技术就应该像是新工具,可以帮助你更好地工作,它自己不应该成为你的工作.
平衡的艺术
- 也许在项目中真正评估技术方案还为时太早.
- 每一门技术都会有有点和缺点.
保持可以发布
已经提交的代码应该随时可以行动.
任何时候只要你没有准备好,就是敌人进攻你最佳的时机.
在团队工作中,修改一些东西的时候必须很谨慎.
如何防止你提交的代码破坏系统的代码?
1. 在本地测试运行.
2. 检出最新的代码
3. 提交代码
保持你的项目时刻可以发布.保证你的系统随时可以编译,运行,测试并立即部署.
平衡的艺术
1. 有时候,做一些大的改动后,你无法花费太多的时间和精力去保证系统一直可以发布.但是这只是例外,不能养成习惯.
2. 如果你不得不让系统长期不可发布,那就做一个分支版本,你可以继续进行自己的试验.如果不行,还可以撤销,从头再来.
3. 千万不能让系统既不可以发布,有不可以插销.
提早集成,频繁集成
在产品的开发过程中,集成是一个主要的风险区域.
独立开发和早期集成之间是具有张力的.
当你独立开发时,会发现开发速度更快,生产效率更高,你可以有效地解决出现的问题.
但并不意味着你避免或者延迟集成.一般需要每天集成几次,最好不要2~3天集成一次.
绝不要做大爆发式的集成.
平衡的艺术
1. 成功的集成就意味着所有的单元测试不停地通过.
2. 每天要和团队其他成员一起集成好几次.
3. 如果你集成的不频繁,也许救会发现整天在解决代码集成带来的问题,而不是专心写代码.
4. 独立开发很好,但是不能独立开发太久,一旦你有了经验就要快速地开始集成.
提早实现自动化部署
如果现在你还是在手工帮助质量保证人员安装应用,花些时间,考虑如何将安装过程自动化.
质量保证人员应该测试部署过程
在项目一开始就应该实现自动化部署.
平衡的艺术
- 一般产品在安装的时候,都需要有相应的软硬件环境.这些环境的不同可能会导致很多问题,所以检查依赖关系,也是安装过程的一部分.
- 在没有征得用户的统一之前,安装程序绝不能删除用户的数据.
- 部署一个紧急修复的bug应该很简单,特别是在生产服务器的环境中.
- 用户应该可以安全且完整地卸载安装程序.
- 如果维护安装脚本变得很困难,那可能是一个早起警告.
使用演示获得频繁的反馈
需求就像流动的油墨.
你无法冻结需求,正如你无法冻结市场,竞争,知识,进化或者成长一样.
没有人的思想和观点可以及时冻结,特别是项目的客户.
不管是什么事情,我们都能做好,不过是以缓慢而逐步的方式.
软件开发的成功就在于最后你离客户的期望有多远.
应该定期的每隔一段时间,与客户进行演示反馈.
如果你能频繁地和用户协商,根据他们的反馈,每个人都可以从中收益.
不一致的术语是导致需求误解的一个主要原因.所以需要维护一个项目术语表.
项目开发应该是清晰可见的开发.
平衡的艺术
演示是用来让客户提出反馈,有助于驾驭项目的方向.
使用段迭代,增量发布
统一过程和敏捷开发都使用迭代和增量开发.
迭代开发是你在小且重复的周期里完成各种开发任务.
对付大项目,最理想的办法就是小步前进,这也是敏捷开发的核心.
大部分用户都是希望现在就有一个够用的软件,而不是在一年之后得到一个超级软件.
询问用户哪些是产品的可用且不可少的核心功能.
不要为所有可能需要华丽功能而分心,不要沉迷于你的想象,而去做那些华而不实的界面.
尽快发布你的应用,迟了也许它就没有作用了.
使用段迭代和增量开发,可以让开发者更加专注于自己的工作.
段迭代让人感觉非常专注且具效率
平衡的艺术
- 如果每个迭代的时间都不够用,要么任务太大,要么因为迭代时间太短,把握好自己的开发节奏.
- 如果发布的功能背离了用户的需求,多半是因为迭代的周期太长了.
- 增量的发布必须是可用的,并且能为用户提供价值.
固定的价格就意味着背叛承诺
软件项目天生就是变化无常的,不可能重复.
开发项目时如何与客户交流?
1. 主动提议先构建系统最小,小的和有用的部分.
2. 第一个迭代结束时客户有两个选择:可以选择一系列新的功能,继承进入下一个迭代.或者可以取消合同.
3. 如果他们选择继续前进,那么这时候,应该就能很好地预测下一个迭代工作.
基于真实工作的评估.
平衡的艺术
1. 如果你对答案不满意,那么看看你是否可以改变问题.
2. 如果你在完成第一个迭代开发之前,拒绝做任何评估,也许你会失去这个合同.
3. 敏捷不是意味着开始编码,我们最终会知道合适可以完成.你需要根据当前的知识和猜想,做一个大致的评估.
4. 如果你别无选择,你不得不提供一个固定的价格,那么你需要学到真正好的评估.
5. 也许你会考虑在合同中确定每一个迭代的固定的价格,但迭代的数量是可以商量的,它可以根据当前的工作状况进行调整.