软件开发的五个优先事项是什么？

Question

在另一家开发公司，我最近在墙上看到了一些项目管理/工作量优先级图。

我习惯了格言“好，快，便宜：选择两个”。但该系统使用了五个指标。那些我记得的：

• 无错误
• 准时
• 功能完成
• 预算

但我不记得第五次了。任何人吗？

在这个系统中，特征请求者给出了五个优先级中的每个优先级为1-5分，其中5表示“非常重要”，1表示“不重要”。没有两个优先事项可以得分相同。这非常好用，因为如果你想要它的Bug Free和Feature Complete，那么On Budget对你来说意义不大 - 但也许对你而言比On Time更重要。

再一次，我所缺少的是第五优先。

Answer 1

我希望这与“可维护”有关。否则你有一个不错的v1，但没有任何迹象表明你可以在没有整个事情发生的情况下添加一个功能。

除此之外，根据您是否将速度计算为特征，有些“高性能”可能属于“功能完成”。 （谷歌的一些人在T恤上有“快速是我最喜欢的功能”......）

还需要考虑的事项：

• 记录完备（可维护？我考虑过开发人员文档，但用户文档也可以来到这里）
• 高效（不仅速度快，而且只需要ZX Spectrum来满足所有网络搜索请求）
• 安全（不会推特客户的信用卡号码）
• 用户友好的

Answer 2

我要提名Extendable。 （又名可维护，未来证明。）

说Extendable的原因在于它可以更好地与业务所有者沟通他们所指定的内容。当你说可维护性时，对于非开发人员来说，这听起来像是在要求他们优先考虑加油和换油是多么容易。

Answer 3

这种n分支图可能有很多版本。

我见过它：

• 无错误
• 准时
• 功能完成
• 预算
• 拥有快乐的团队

措辞和重点是我的，但基本上，作者补充说，是的，推动你的团队疯狂加班是你可以牺牲的事情的一部分，但质量或预算，你最终支付它某种方式。

Answer 4

客户需要什么，而不是他认为他需要什么。

Answer 5

不确定五分之一可能是什么，或者它是不会被“主要”四分之一所暗示的东西，但是在“规划极限编程”的第7章中对这四个有一个很好的解释，你可以查看部分页面here

Answer 6

啊......看来我看到的是基于Rob Thomsett's "Success Sliders"。虽然他有七个滑块，但我看到的只有五个（看起来两个优先级可以分享相同的分数）：

1. 让利益相关者满意。
2. 实现功能要求
3. 会议预算
4. 会议截止日期
5. 增值
6. 确保高质量
7. 让团队成员满意

我认为1是通过成功完成2-6来完成的。良好的质量将是无错误的优先级。所以我们留下了“增值”或“让团队满意”。听起来都不熟悉。我将不得不重新与公司联系并询问。

Answer 7

迟到的答案，但我相信现有的回复会有一些补充。我相信标准的“一刀切”优先级图的整体思路不仅仅是错误的，而是危险的。

广泛接受的项目维度

管理界的一般协议似乎是一个项目可以分为四个维度：

• 范围
• 时间
• 成本
• 质量

当您尝试进一步细分这些维度，测量它们或查看它们相互影响的方式以确定优先级时，事情开始变得模糊。

<强>相互依赖

在软件中，通常范围意味着功能要求（软件做什么以及不应该做什么）以及完成向客户交付软件所需的任何辅助要求。当然，范围会影响项目时间，成本，功能和非功能质量。

让我们说企业有一个固定的机会窗口来击败竞争对手或提供一些服务和现金。时间明显优先于范围;系统的各个部分可以在软件外部完成。

但对于火箭发动机控制软件而言，范围可能是不可协商的，并且当它随着时间的推移而优先时。类似地，所有维度之间都存在相互依赖性。

无尽的切片

可以进一步切割尺寸：缩短开发时间，降低系统效率和效率（软件维护和使用时间损失），较小的开发成本与较高的总体拥有成本和较短的使用寿命（导致较小的投资回报） ），使用更高的多功能性与难以学习的模式。

质量可能最多被划分为更多类别，其中许多涉及相互冲突的选择：

• 功能：
  • 功能的可用性（spoken, unspoken, excitement）
  • 功能的稳健性（缺陷，一致性，集成性，整体性）
• Non-functional：
  • 可用性
  • 可维护性和设计可扩展性
  • 性能
  • 运营和环境
  • 法律（和其他标准）合规性
  • 文化（国际化，本地化）
  • 外观和感觉
  • 安全
  • 政治

将一个软件生态系统分成几类的过程可能是无穷无尽的。并且还有无数的方法来衡量软件项目的成功或失败。包括利益相关者的满意度，开发团队实际上也与项目有关，因此他们的满意度很重要。

简化有害

软件设计是在这些类别之间进行一系列权衡的结果。正如烹饪美食一样，根据环境，客户要求，过敏和配料供应情况，可以采用无穷无尽的方式组合成分。

最好避免简化，在海报上放置一张海报，其中Cost总是优先于Scope，或者可维护性比Look and Feel更重要。项目经理的工作是牢记整体情况，并根据具体情况向团队成员提供每日制定优先级决策的指导。

一个PM不能被墙上的图表取代，一个好的PM也不应该试图将她或他的工作的本质外包给一张纸。

Answer 8

在jon：scaleable

的行中

Answer 9

满足用户的需求？

Answer 10

作为替代方案：

高效

• 如果需要永久性地使用功能完整的软件，或者需要一些愚蠢的硬件，那就没有好处....

Answer 11

我会添加“ USABLE ”。 可用性是我们程序员倾向于忘记的一个非常重要的因素。具有良好可用性的软件减少了用户学习曲线中的许多问题，并且比具有相同功能但在可用性方面不太好的其他软件更“更快”地“使用”。

Answer 12

我认为这可能是“记录良好”

Answer 13

我自己的名单：

1. 确保满足业务功能目标。
2. 努力实现模块化和可维护性。
3. 避免范围蔓延。
4. 与业务分析师和项目经理保持良好的关系。
5. 不要烧桥。

我想补充一点，应该优先考虑每个开发人员的专业和享受的范围，并尝试适应他们。不要给作为WCF的艺术家的开发人员提供涉及UI更改的项目，不要给游戏开发人员一个SQL datafix项目（除非在任何一种情况下，他们特别要求这样做）。

如果您注意到您的员工擅长什么，部分基于他们的跟踪记录，并相应地分配任务，那么他们将比其他人更有效地完成工作，而对于他们来说，特殊任务要么是陌生的，要么是不利的境。

Answer 14

正如所承诺的，这是我最初看到的清单：

• 功能齐全
• 准时
• 预算
• 无错误
• 适合目的

所以我错过了“适合目的”，这是可以理解的：它与'功能完整'之间的区别有点难以确定。

以下是朋友给我的一个例子：

  

作为一个简单的例子，如果客户将完整性评为高，并且适合低，则意味着他们既需要在线产品目录又需要购物车设施，即使这两个功能都非常简陋。相反，如果完整性较低且适合度较高，则客户可以在第一个版本中接受功能齐全的产品目录，而不是购物车设施。