第三章: 定义范围和估算
在大多数的组织里,项目经理与客户和管理层协调工作来建立项目的范围以及估计时间和所需要用到的资源.在这些任务中项目经理经常性地依赖于架构师的帮助.这样的情形在J2EE应用里也不例外.这章的内容是架构师的责任,包括帮助项目经理定义和估计交付.不涉及到此部分的读者可以跳过这一章.
定义范围
客观的根据用例定义项目的范围,并且获得客户的同意.在项目因为时间或者开发组成员士气低落的时候就需要调整项目范围.当客户在开发已经进行后又提出新的需求时,用用例将它们记录下来,然后计划在下一个发布版本中加入它们.通常,为每一个用例进行粗略的估计会得到一些信息,对客户来说这些信息在决定项目范围时很有用.
在用例上得到项目发起人的同意.当用例是用商业术语书写时,它们能被看成是与客户和管理层的"合同"被提交.与客户合作去选择哪些用例需要在当前项目中实现,另外的将被推迟实现.即然项目范围在口头上同意了,也需要书写或以E-MAIL的形式通知与此项目相关的所有人.确保保留一个拷贝.
一旦项目范围确定下来,要坚持不懈的执行.项目经理在项目范围被确定能做的最重要的事就是执行它.架构师有责任提醒项目经理改变项目范围.去击打一个移动的目标是很难的(译注:要改动一个执行中的计划也是很难的).虽然我一般更愿意去为将来的版本计划所有改进,但架构师通常没有这样的计划.我评估需求是按用例的形式来进行,并且提供一个原始的估计.通常,项目经理使用这些信息来指引客户去计划今后版本的需求.
第三章完
在大多数的组织里,项目经理与客户和管理层协调工作来建立项目的范围以及估计时间和所需要用到的资源.在这些任务中项目经理经常性地依赖于架构师的帮助.这样的情形在J2EE应用里也不例外.这章的内容是架构师的责任,包括帮助项目经理定义和估计交付.不涉及到此部分的读者可以跳过这一章.
定义范围
客观的根据用例定义项目的范围,并且获得客户的同意.在项目因为时间或者开发组成员士气低落的时候就需要调整项目范围.当客户在开发已经进行后又提出新的需求时,用用例将它们记录下来,然后计划在下一个发布版本中加入它们.通常,为每一个用例进行粗略的估计会得到一些信息,对客户来说这些信息在决定项目范围时很有用.
在用例上得到项目发起人的同意.当用例是用商业术语书写时,它们能被看成是与客户和管理层的"合同"被提交.与客户合作去选择哪些用例需要在当前项目中实现,另外的将被推迟实现.即然项目范围在口头上同意了,也需要书写或以E-MAIL的形式通知与此项目相关的所有人.确保保留一个拷贝.
一旦项目范围确定下来,要坚持不懈的执行.项目经理在项目范围被确定能做的最重要的事就是执行它.架构师有责任提醒项目经理改变项目范围.去击打一个移动的目标是很难的(译注:要改动一个执行中的计划也是很难的).虽然我一般更愿意去为将来的版本计划所有改进,但架构师通常没有这样的计划.我评估需求是按用例的形式来进行,并且提供一个原始的估计.通常,项目经理使用这些信息来指引客户去计划今后版本的需求.
第三章完
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
