我是一家非常小的公司的独立开发人员。我的工作非常混乱，我正在寻找方法使其更有条理。
一个问题是我的项目实际上没有管理。很少有人问我正在做什么，或者我有什么问题。在某些时候，有人谈论每周一次的状态会议，但那是一段时间以前。似乎如果我想要这样的东西，我将不得不自己安排。有时我会因为我没有完成任务或明确的时间表而对我应该做的事情感到有点迷失。
从书籍和文章中我发现了许多可能有用的东西。就像有一个好的编码标准（在我看来只有一个粗略的风格指南，有点过时），代码检查，TDD，单元测试，错误数据库...但在一个小公司，它似乎没有资源或时间任何不重要的事情。我在嵌入式域中工作的事实似乎使事情变得更加复杂。
我觉得在短时间内也有偷工减料的习惯。这导致未完成和不专业的产品和错误等待在以后出现。我想他们也很难维持。所以，我即将继承一个具有挑战性的代码库，进行新的开发，需要学习很多新东西，我想尝试同时为它们构建一个流程。它最终可能会有所回报，但由于没有太多经验，我不确定我能不能把它拉下来。
在这样的小商店里，环境远不是编程的最佳选择。还有许多其他事情需要偶尔完成，如客户支持，接听电话，签署包裹，硬件测试，装配以及可能出现的任何其他任务。所以你了解了资源。这并不全是坏事（有时解决一些客户问题很有启发性），我相信它可以改进，但这是我真正关心的其他事情。
是否可以在这样的地方进行开发？
进行某种管理会有所帮助吗？什么样的？
是否可以用小资源制作优质产品？
我如何让自己和其他人相信几十年来成功运作的公司需要改变？什么是必要的？
也许有人在类似的商店工作？
答案 0 :(得分：17)
答案 1 :(得分：6)
我的建议不是极端。根据我的经验，纯粹的敏捷或纯粹的传统将无法奏效。在使用任何流程之前，请先了解解决的问题。
我个人使用Agile RUP的变体。我做了一些前期工作，比如调查实际需求，做可能扩展的高级设计。并要求客户签署一些主要的高级要求。
如果您在小组工作，详细设计或规格可能不值得。当然，如果有一些库被许多人共享，那将是值得的。
根据风险（可能性和影响）确定预先投资的内容。
此外，许多SW最佳实践真的是“最好的”，如版本控制，自动测试（对我来说，我只是用它来早期检测回归，因为我不相信TDD是开发的驱动力）。我建议你阅读'Pragmatic Programmer'，它提供了许多技术。
至于回答你的问题：
（1）。是否可以在这样的地方进行开发？
是的，但正如我所说，预告它适合您的组织。
（2）。进行某种管理会有所帮助吗？什么样的？
管理层帮助但没有控制权。计划在做什么时：整合，解决冲突，某些里程碑的死线。并且大致按时完成（我特别喜欢Scrum的冲刺）。
（3）。是否有可能用小资源制造优质产品？
绝对一旦工作的规模，发展的时间和团队的规模是平衡的。如果您对Quality的定义与我相同。对我而言，质量意味着：以高效可靠的方式解决它所面临的问题。
（4）。我如何让自己和其他人相信，几十年来成功运作的公司需要改变？什么是必要的？
指出问题所在。如果没有，为什么要改变？如果您想要更改，您应该能够识别问题或潜在问题。指出问题。
一些重要的是：
没有任何过程，新招募的人很难融入，因为他们必须从观察其他如何处理事情中学习。
没有过程，就很难在压力下工作。
如果没有时间表，很难确定进度。
如果没有自动测试，则需要更多时间来识别问题和回归。
如果没有版本控制，就会更难回滚错误，并且每个团队成员的工作分离都会变得一团糟。
就是我的。
答案 2 :(得分：2)
您需要与所有者合作并设置短期中期和长期目标。即使只是通过电子邮件，您也希望让他们了解进度。
您需要在工作日强制执行某些订单，否则您将无法完成任何工作（这些长期目标）。
当您可以编码时，将您的一天划分为块，当您正在处理黑客攻击时，以及在回复电子邮件等时将其划分为
。绝对设置错误跟踪器。这可以帮助您保持电子邮件的清洁。您甚至可以设置电子邮件地址以转发稍后要归类的错误。这很好，因为bug报告者最终会厌倦bug追踪器，并且只想给你发错误邮件。
修改
正如lod3n所说，源代码控制，但你正在使用它已经正确??? !!？！
答案 3 :(得分：2)
去过那里，做到了。
这本书Planning Extreme Programming帮了很大忙。我用3x5卡贴在墙上。这使我的老板了解我的进展，帮助估算和计划，并使我保持正轨。如果你的老板的期望不切实际，那么规划游戏会提供很好的弹药。
正如其他人所说，单元测试即使您是唯一的开发人员也会有所帮助。我发现TDD风格很有价值。
lod3n对于源代码控制是绝对正确的。
之前我已经使用过XP风格的迭代了;你可能想要建立一个积压的项目（甚至像电子表格或3x5卡片一样简单）。
避免死亡之旅。在连续2周不加班的意义上坚持40小时。花更多时间在工作之外学习新技能 - 不仅仅是技术，还有原则和最佳实践。
答案 4 :(得分：1)
拥有错误跟踪系统，包括缺陷和新功能。不要依赖你的记忆。
持续集成和自动构建甚至可以帮助单个开发人员。
不能足够强调源控制的建议。
答案 5 :(得分：1)
我已经决定我don't need unit tests because I can have automated functional/integration tests instead：因为通过增量开发，无需在集成之前进行测试。
答案 6 :(得分：1)
答案 7 :(得分：0)
除了其他人的推荐之外，我会说，如果你对资源紧张但对如何完成工作有更多的发言权，你应该好好利用现成的开源产品和库。这可以充分利用他人的努力，节省您的时间，确保您的代码库不会变得过于深奥并增加您的技能组合，这样您就不会成为其他地方无用的专家。
答案 8 :(得分：-1)
首先，让我们区分开发过程和最佳实践。源控制，缺陷跟踪，单元测试等最佳实践是给定的。
然后是实际的开发过程。我总是建议有一个过程，无论团队规模大小。诀窍是找到正确的流程。你现在有一个过程 - 它只是一个特别的过程，对你来说似乎并不是很好。您很少能参加教科书开发过程并直接应用它。您需要做的是根据您公司的需求和文化来定制流程。看看尽可能多的开发范例，并尝试找到一个非常合适的东西，然后开始根据您的需求进行塑造。您可能必须通过许多不同的过程尝试失败。也许个人软件过程将是一个很好的启动过程，也许是敏捷过程，RUP的变体？你有很多选择，开始尝试它们。
您还必须与组织的其他成员合作 - 他们需要成为流程的一部分。您可能是唯一的开发人员，但开发过程涉及的不仅仅是开发人员，而是涉及对产品有发言权或影响力的人。
这可能不是一个具体的答案，但我的观点是你需要某种过程。因此，开始研究它们并尝试将它们塑造成适合您的需求，直到您有一些有效的方法。