这是正常的开发程序吗？答案

【问题标题】：Is This Normal Development Procedure?这是正常的开发程序吗？
【发布时间】：2009-10-26 17:51:57
【问题描述】：

首先介绍一下我自己。我不是经验丰富的软件工程师、架构师或开发人员。在过去的 5 年中，我主要使用 C# 完成了小型 ASP 和 ASP.NET 项目。我非常擅长 HTML 和 JavaScript。这些项目是在我有空闲时间完成与软件开发无关的其他工作时完成的。我现在被调到了软件开发人员的位置。我工作的公司不是软件开发公司。

我现在正在使用 WCF 和实体框架开发 Silverlight LOB 应用程序。这个项目给我的规范很少，只是“制作一个像 X 一样的应用程序，只是更简单，所以我们不必为此付费”，我的老板并没有像我认为的那样经常检查我的进度，项目经理（同事）会时不时停下来，但我们从不讨论规格、架构、UI 或业务规则。我大多只是被问到我认为什么时候会完成。我必须学习 Silverlight、WCF 和 Entity Framework 才能从事这个项目，这不是问题，因为我真的很喜欢使用这些技术。问题是我是公司里唯一一个对这些一无所知并且没有导师/老板来讨论问题以及如何解决问题的人。我已经能够找到公司中的一个感兴趣的人，该人至少给了我一些要求的清单。

我不敢相信这就是软件开发的方式。我认为项目经理应该提供指导，并密切关注正在采取哪些措施来防止误入歧途（但在我的情况下，他们怎么能不了解技术！）。

我应该有这种感觉还是我离谱？

感谢收听。

【问题讨论】：

标签： wcf silverlight entity-framework

【解决方案1】：

您所描述的情况肯定不是最佳的，但它非常普遍，尤其是在较小的商店中。有些人发现在这种环境中工作很有意义。这不是软件工程书籍所教的，但这就是为什么有这么多软件工程书籍的原因。

如果您想继续在这种环境中工作，您将必须提供所有您正确认为缺少自我的纪律。写一个规范。制定时间表。与您的管理层分享这些信息。坚持到最后期限。

与您的管理层分享您的疑虑；不要害羞。很有可能，他们认识到了这种情况。你的老板不检查你的进度？向他公布你的进展。告诉他你需要去哪里，你走了多远，什么阻碍了你。

毫无疑问，这会很混乱，但你会学到很多东西。

【讨论】：

此外，当项目失败并受到指责时，您提供的所有文件都可以作为您辩护的证据。 :-)
+1 表示乐观地看待我认为相当暗淡的环境 :)
+1 很多优点。我特别喜欢向老板公布你的进展。我会把这些付诸实践。
+1 获得高分。这种环境可能令人沮丧，但它也提供了绝对最好的机会。如果你做得好并且完成了项目，你可以将整个事情添加到你的简历中——一个概念到支持的开发周期。纯金。

【解决方案2】：

每个组织都是不同的。如果他们以这种身份运作，那么您应该适应并充分利用这种情况。发生这种情况要么是因为事情就是这样完成的并且他们意识到了这一点，要么他们不知道更明智或不想投资以改进交付战略/战术项目的过程。

在一个完美的世界中，每个人都应该拥有一套健全的质量方法，该方法将为项目交付和系统实施提供一个框架。这不是现实。

以下提示可帮助您更有效地运营：

确定您的赞助商（拥有产品的人）并确定他们寻求解决的业务问题的高层次利益和驱动目标
确定您的利益相关者（谁有影响力和谁感兴趣）并让他们尽可能多地传达他们的需求
尽可能多地或尽可能多地让赞助商和利益相关者参与到流程中
通过书面形式（电子邮件）从他们那里获取您可以提出的要求
让他们有机会了解交付情况并提供反馈

【讨论】：

所有回复中都有很多好主意。我想我可以实现这里提出的几个要点。感谢大家的意见。

【解决方案3】：

从老板的角度来看，您的项目可能会失败。因为我确定你开发的程序不适合他。但你不会感到内疚。这是你老板的痛苦。（因为你是优秀的程序员）。抱歉发了这么黑的帖子:-)。

【讨论】：

【解决方案4】：

项目经理的角色不是了解技术，但他们绝对应该掌握项目的脉搏，可以这么说。真正的项目管理工作不是控制项目，而是启用它。无论哪种方式，从您的描述来看，您的工作似乎都不是很好。

另一个极端是流程繁重的组织，会议和委员会决定一切，所有真正的沟通（如果存在的话）都是通过辅助渠道进行的。

理想世界介于两者之间。

你的项目经理不应该太关心你的工作方式。由于他们没有资格，他们能做的最好的就是将您与有资格的人联系起来。当他们无法验证您正在构建正确的东西时，他们至少应该确保您正在构建正确的东西。即使是内部使用，你还是有客户的，和客户没有交流对我来说是个坏消息。 :)

如果您的 PM 不关心这个问题，您可以尝试自己做一些事情。例如，要求 PM 将您与该应用程序的潜在最终用户联系起来。提取应用程序的一些部分，然后将它们提供给用户使用——只要确保你提供给它们的部分看起来或感觉不太完整。

如果您无法改变事情，请将其作为学习经验。确保下次您准备进行项目时，您知道上次出错的地方，并尝试从一开始就减轻它们的影响。

最后，如果你的老板告诉你这是一种“更灵活”的工作方式，那就打他们的脸。敏捷是或应该是纪律的代名词，而不是完全缺乏纪律。

祝你好运！

【讨论】：

【解决方案5】：

这是一个艰难的情况。只有您才能真正确定进行的最佳方式。但是，我确实认为对时间表和同时缺乏文档（要求、期望、用例场景文档等）的担忧是等待发生的火车残骸。即使是最敏锐、最有经验的开发团队也会遇到同样的问题。

“什么时候完成？”最好通过定期提供小型部分功能构建来缓解问题，您可以使用这些构建从移动目标（即您的客户）中获取有用的信息。当某人（您的老板/客户/最终用户）实际上可以“玩”他们面前的某些东西并重新考虑他们真正想要的东西时，会发生如此多的交流，这真是令人惊讶。

【讨论】：