如何克服结构不良的软件开发模型？

我刚加入公司，现在正在从事工作。由于GIS软件开发领域的技术人才有限，而且由于我是其中之一，因此我被直接聘为项目经理。

我非常熟悉Java和GIS，并且我对基于位置的服务进行了自发性的研究，但没有进行项目管理和结构化软件开发。我是地质学专业的毕业后一年，而在前一年，我在大学里担任学者。

多亏了我在工作中的兴趣，出现了一个机会，最终我也被任命为公司的商务智能部门的负责人。公司相信我。我本人研究了数据仓库和BI概念，并成功地将GIS与BI相结合。

另外，我目前正在与两个开发人员一起使用C＃WPF中的BI工具，在其中我有时也扮演开发人员的角色（我很喜欢）。

我非常努力地通过敏捷项目管理来采用良好的软件开发方法，但是这种方法并不是很成功。同样，尽管我相信就产品而言设计良好的代码，但由于我的首席执行官（直接在我之上）缺乏技术知识，所以我通常没有足够的时间来做。由于我们也缺乏整体上对特定编码语言的专业知识（例如，与Java相对的WPF），因此所花费的时间大大增加了。也没有适当的版本控制系统。

我对事物的运行方式非常无聊，因为它不是结构化的，我发现大部分时间都在思考如何使事物结构化。我希望你们有良好的专业经验，能够帮助我克服这种情况。

大约两年前，我在公司工作时遇到了类似的问题（当然，没有技术细节）。

您只需要一次完成一个步骤。不要急于采用敏捷软件开发。有很多东西要学习和应用。也不要让缺乏专业知识的人失望。

稳定，可靠地缓慢构建（但要尽可能快：P）。

我建议您采取以下步骤（为此，您可能需要一段时间从管理切换到开发，但这应该没问题）

1. 学习一个好的版本控制系统，并学习它。我个人建议git或mercurial。两者都有很多文档。
2. 在实践和模式上建立坚实的核心。与团队成员一起阅读书籍，阅读博客和观看截屏视频。这将为开发注入新的活力。
3. 了解TDD / BDD并尝试将其应用到新代码以及执行新功能时可能碰到的旧代码中。
4. 进行配对编程。有两个脑袋比一个脑袋好，还有四个眼睛比两个眼好：）。
5. 查找有关的最新和最常见的常用工具，在当前开发语言的社区。了解它们，并尝试将其中一些包含在项目中。看看这些是如何构建的并学习。
6. 使用scrum。迭代，故事，故事要点，障碍都是您应该熟悉的所有概念。对我来说，Scrum被证明是软件开发和管理的最佳工作流程。应用它并从每天的经验中学习。
7. 以身作则。大多数初学者开发人员都渴望学习新知识，但其中一些人也很懒。无论如何，向他们展示您一直在学习和应用的新知识，并希望它们能使他们的大脑发痒。

另外，如果可能，请聘请顾问，以便他可以检查流程并提供更好的建议。

不要懒惰或灰心。只需从错误中学习，然后尝试其他方法即可。这仅仅是开始！

编辑：

这是我最近一直在阅读/使用的一些链接和书...

学习git：Pro Git

这些是我推荐的一些博客（大多数博客都是面向.NET的）：

• Java博客
• Karl Seguin的博客及其编程基础丛书。
• CodeBetter.com
• 代码思考
• 洛杉矶技术
• 清洁编码器
• 还有这个指向堆栈溢出问题的链接。

对于书籍，您可以在Amazon上看到“ 建立坚实的编程核心”列表。我还建议这些：

• 清洁代码
• 敏捷软件开发，原理，模式和实践
• 实用书架上的几乎所有书籍

作为经理，获得正确完成项目所需的时间是您的工作。与首席执行官接洽时，请确保您有所有数字作为后盾，并说明为什么估算值要这么长。这是你作为管理者的责任，以使该CEO明白为什么需要ñ小时/天/周才能完成既定任务。有时候这可能很困难，但是我还没有遇到一位希望他的公司倒闭的首席执行官，我敢打赌，如果用这种方式（如果其他所有倒闭的话）来形容，他可能会改变自己的看法。

如果首席执行官不愿意给您时间来完成任务，那么恕我直言，准备好继续从事其他工作或为持续的死亡游行做准备。作为最后的选择，向首席执行官解释无疑会因不切实际的期望而产生的倦怠感。

话虽如此，您还需要确保开发人员为您提供准确的估算值（非常困难，如果不进行适当的技术设计，这几乎是不可能的，这也应该放在适当的位置）。

敏捷并非在所有开发领域都很好。为某些项目类型工作，而在其他项目类型上却惨败。您可能必须尝试一些不同的方法，你找到一个工作之前很好。

获取版本控制设置。确实，设置Git需要5到10分钟，要花费一些时间才能完成基本操作，需要一两天的阅读时间来获得更高级的概念。

嗯，不确定我是否在多伦多的敏捷/ XP活动上遇见了您-听起来很熟悉

听起来您需要休息一下。花一个漫长的周末，如果愿意的话喝醉，然后几天忘了工作。

放松自己。自我教学是好的，而且仅仅是因为一种方法论不适用于所涉及的性格，并不意味着您做错了，也不是个人的失败。

有一个针对项目管理的pm.stackexchange.com（测试版）网站，您可能在那里会获得一些有用的建议/支持-但无论如何，也请在此处提出问题。

继续讲技术的东西：

没有适当的版本控制系统

优先考虑一个。我喜欢像SVN（Subversion）这样的集中式系统而不是git / mercurial，因为被盗的笔记本电脑在本地不会有太多的历史记录。如果任何超级机密（例如密码和ssh-key）被错误地签入，则尤其重要。但这是一个品味问题。没有比“手动版本控制”中的错误浪费更多的时间了-例如将代码恢复到您认为的样子。

祝好运

听起来您有几个问题：1.与非技术高级管理层进行沟通，以便他们支持您的改进计划；2.推动改进计划以取得成功。

数字1最难的部分只是记住，高级管理人员通常对您正在研究的细节不感兴趣。（如果是的话，他们会自己做而不是交给您！）听起来最大的障碍是“为什么”，您可能希望查看CMM 1.1，以描述流程改进的业务优势。程序。无论您使用CMM还是其他方法来真正改善您的流程，对于本次讨论都没有关系，仅来自卡内基-梅隆研究的数据表明，成熟的组织可以更快地交付项目，交付时间的差异更少。

在过程改进方面有很多成功之路，所有这些都往往很长。从CMM的经验表明，从1级升级到5级可能需要8到10年的时间。6 sigma的经验表明，每次迭代都有一定的改进，但是需要多次迭代才能消除大多数潜在的问题，并且在您到达时质量为6 sigmas，工作方式完全不同，而不必冒险尝试一次更换所有东西。

如果您的行业中普遍使用质量改进方法，请花一些时间尝试看看如何将其应用于软件并加以使用，以便公司的其他成员听到他们已经熟悉并支持的知识。我们可以谈论几个小时，讨论特定的软件工具和实践，但是非软件行业的CEO将迅速对其进行调整。谈论行业的标准做法，他会振作起来，因为您在说他的语言。以业界通用术语谈论软件，他将开始提出相关问题，以更好地理解您的挑战以及为改善公司业绩而制定的计划。

这样一来，您不会赢得所有要求支持的东西，但是您可能会得到更少的空白外观和更多的胜利！

先生，祝你好运！

您的所有建议确实是明智的，并且是许多公司的必经之路。但是它们并不是通用的，特别是对于那些没有经验的团队。他们之所以不是这样，是因为他们需要大量的工作来设置和维护-甚至是版本控制-许多人认为这是任何软件项目的赌注。因为他们需要一些工作，所以他们也需要提供一些好处。在您的特定情况下，可能情况并非如此！至少，负责制定决策的人没有看到好处！

正如其他人指出的那样，您需要：

• 尝试轮流采用这些做法。不要一次尝试所有这些，因为它会使人不知所措。
• 您需要为此确定一个好的顺序。我将从版本控制开始。然后也去轻松点吧。一旦人们开始相信您可以做出明智的决定，并且他们看到了收益，他们将更有可能采取更具风险的变革。
• 为为什么需要实施某些措施建立可靠的案例。由于有2-3个不断向最终用户显示进度的开发人员，因此很难证明采用更复杂的开发方法是合理的。您将被视为关注流程而非关注结果。
• 请记住您需要说服谁。开发者？老总