|
|
1
2
向经理解释情况,让他决定。这就是他在那里的原因。 如果你负责,那么你需要考虑所有的可能性。我想说的是,在第一轮中关注客户需要什么,然后完成第二优先功能。如果可能的话,与他们交谈、解释并试图达成一致。客户可能对他最需要的东西有不同的意见,并为您提供方向,让您集中精力。 |
|
|
2
1
以对客户/企业更有利的为准。如果有可能让所有7个“特性”都处于半完整状态,那么就去做吧。如果他们更喜欢3个抛光的“特征”,请走这条路。 |
|
|
3
1
这取决于客户的价值观。 模块真的是独立的吗?它们是否真的完全需要,或者即使部分实现,它们也能提供价值? 一个有用的策略是跨系统甚至模块实现垂直切片,而不是模块的水平层。一次实现一个端到端特性/用例/用户故事。正是这些功能为您的客户带来了价值,而不是模块(除非客户是一个重视模块而不是功能的古怪客户)。通过这种方式,您可以为测试和发布做一些有用的准备,并且您的时间不会花在编写任何人都不使用的代码上。但是,在添加新特性时,您需要继续重构代码库,以避免 stovepipe system anti-pattern . 在任何情况下,实施7个模块的一半都不是答案。无论你做什么,第一次就做好。(“正确”当然取决于上下文:不同的标准适用于一次性原型、生命关键型生产代码以及两者之间的一切。) |
|
4
0
完成3个步骤。
|
|
|
5
0
这在很大程度上取决于您的开发模式和客户需求。在敏捷环境中,我宁愿展示完整的产品(即使是未完成/模拟的部分),这样客户就可以对其整体有一个印象,并可以就未完成的模块向您提供早期反馈。
|
|
|
6
0
客户清楚地知道他想要什么,我的工作是向他展示一些能吸引他的注意力的东西,给我额外的时间来完成项目。 |