第九区

一个程序员的经验笔记

三-交付用户想要的软件

| 暂无评论

客户总会有很多需求不在当初的需求文档里,我们要保持代码随时可发布,以通过演示获得频繁反馈。固定的价格意味着背叛承诺,要保持价格不变只能牺牲代码质量。
让客户做决定
记录客户做出的决定并注明原因,可以用WIKI、日记或邮件,不要太繁琐就行。对业务人员的业务有影响的问题,都是有价值的。如果问题对业务没有影响,就不要去打扰业务人员,反之,则应该尽早获得他们的认可。如果业务人员回答我不知道,这也是一个好答案,应该尽力提供建议,并在实现代码时考虑可能的变化。
让设计指导而不是操纵开发
设计分为战略和战术两层,前期设计只描述总体战略,不应深入具体的细节。战略级别设计不应该具体说明程序方法、参数、字段等精确的程序细节。好的设计应该是正确的而不是精确的,不应涉及正确的或可能变化的细节。计划是没有价值的,但计划的过程必不可少。草图和便利贴都是很好的设计工具,复杂的建模工具只会分散精力。
合理地使用技术
选择一门技术前要弄清它的利弊,只有在一项技术确实能解决当前问题的时候才选择它。不要开发你容易下载到的东西。
保持可以发布
始终坚持一个简单的工作流程:在本地测试,检出最新代码,提交代码,就可以让你的项目始终保持可发布状态。如果某个项目确实很难做到随时可以发布,那么可以建立一个分支。这样,任何时候,你的老板、客户或是女朋友来参观项目,你都可以毫不犹豫地给他们演示最新构建的软件。
提早集成,频繁集成
成功的集成意味着代码反复通过测试。每当代码能够正常工作时就应该集成。
提早实现自动化部署
WEB项目部署方面的问题不大,但在一开始就提前部署显然是必要的。
使用演示获得频繁反馈
需求不可能冻结,生产出客户曾经要求过的软件而不是他们现在真正想要的,结果必然会让人失望。频繁演示应该尊重客户的时间,以客户可以接受的时间间隔为准。完成一些功能可以演示时才和客户碰面些,演示必须具备功能和稳定性。
使用短迭代增量发布
再大的项目也要应该先完成最小可用功能块,使用1~4周左右的迭代周期进行增量开发,在4周迭代中间安排一周维护任务比较适合。迭代的时间应该按实际情况调整,如果时间不够用,那么应该是任务太大或时间太短;如果功能背离了用户需求,那么多半是迭代周期太长了。增量的发布必须是可用的,并能为用户提供价值。
固定的价格意味着背叛承诺
软件项目天生变幻无常,不可能提前给出固定价格,对于大型项目如政府合约,可以用COCOMO模型或Function Point analysis,但它们都不属于敏捷方法,且本身代价高昂;如果项目具有普遍性,则可以根据之前的同类项目进行估价;除此之外,大多数情况下,可以主动建议先完成最小可用功能,在8周内完成交付,随后每次和顾客商定增加哪些功能,继续下一个迭代,或中止开发,由客户选择其它团队继续完成。对用户来说,这样可以大大降低项目失败的损失和风险,而我们则可以如愿进行迭代开发。如果客户坚持要求先给出固定价格,或许可以在方案中确定每个迭代的固定价格,但说明迭代数量可以试情况进行调整。无论如何,如果你拒绝事先估价,就很可能失去这个合同,无论竞争者的承诺如何不切实际。

发表评论

*为必填字段!