独立开发人员应该开发哪种软件开发stream程？
我作为一个非常小的公司的独立开发人员工作。 我的工作非常混乱，我正在寻找方法使其更有条理。
一个问题是我的项目实际上没有pipe理。 很less有人问我在做什么，或者我有什么问题。 在某个时候，每周都会举行一次关于每周一次的会议，但是那是前一段时间。 似乎如果我想要这样的事情，我将不得不自己安排这些事情。有时候，我对接下来应该做的事情有点遗憾，因为我没有任务或明确的时间表。
从书籍和文章中，我发现很多可能有用的东西。 代码检查，TDD，unit testing，缺陷数据库等等，就像有一个好的编码标准（只存在一个粗略的风格指南，这在我看来已经有些过时了）。但是在一个小公司里，似乎没有资源或时间任何不重要的东西。 我在embedded式领域工作的事实似乎让事情变得更加复杂。
我觉得还有一个偷工减料的习惯，在短时间内做快速的黑客攻击。 这导致未完成和不专业的产品和错误等待在以后出现。 我会想象他们也是一个痛苦的维持。 所以，我即将inheritance一个具有挑战性的代码库，做新的开发，需要学习许多新的东西，我想同时build立一个过程。 这可能是最后的奖励，但是由于不太经验，我不确定是否可以把它closures。
在像这样的小商店里，环境对于编程来说是远远不够的。 还有很多其他的事情需要偶尔进行，如客户支持，接听电话，签名包裹，硬件testing，组装以及任何可能出现的各种任务。 所以你得到关于资源的想法。 这并不坏（有时解决一些客户问题有启发性），我相信它可以改进，但是我真正关心的是其他事情。
是否有可能在这样的地方开发？
这有助于进行某种pipe理吗？ 什么样的？
是否有可能用小资源制造高质量的产品？
我如何说服自己和其他人，几十年来成功运作的公司需要改变？ 什么将是至关重要的？
也许有人在类似的店里工作？
我的build议不是极端的。 从我的经验来看，纯粹的敏捷或纯粹的传统是行不通的。 在使用任何stream程之前，请先了解要解决的问题。
我个人使用了Agile RUP的变体。 我做了一些前瞻性的工作，如调查实际需要，做可能的延伸的高层次的devise。 并要求客户签署一些重要的高级要求。
如果你在小组工作，细节devise或规格可能不值得。 当然，如果有一些图书馆被许多人共享，这将是值得的。
根据风险（可能性和影响）决定先投资什么。
此外，许多SW最佳实践是版本控制，自动testing（对我来说，我只是用它来检测回归，因为我不相信TDD是发展的驱动力），真的是“最好的”。 我build议你阅读“ 实用程序员 ”，它提供了许多技术。
至于回答你的问题：
（1）。 是否有可能在这样的地方开发？
是的，但正如我所说，拖车它适合您的组织。
（2）。 这有助于进行某种pipe理吗？ 什么样的？
pipe理帮助，但没有控制怪胎。 计划在什么时候做：整合，解决冲突，死里程碑。 大致保持它们如期（我特别喜欢Scrum的冲刺）。
（3）。 是否有可能用小资源制造高质量的产品？
一旦工作的规模，发展的时间和团队的规模都是平衡的。 如果你对质量的定义跟我一样。 对我来说，质量意味着：以高效可靠的方式解决问题。
（4）。 我如何说服自己和其他人，几十年来成功运作的公司需要改变？ 什么将是至关重要的？
指出问题。 如果没有，为什么改变？ 如果你想改变，你应该能够找出问题或潜在的问题。 指出这个问题。
一些大的是：
-
没有任何过程，新招聘的人难以融入，因为他们必须学习观察其他如何处理事情。
-
没有过程，压力就更难了。
-
没有时间表，很难确定进度。
-
没有自动testing，需要更多的时间来发现问题和回归。
-
如果没有版本控制，将会更加难以回滚错误，工作分工让每个团队成员都会一团糟。
只是我的。
- 使用源代码pipe理一切
- 制定规格并在开始之前得到签收 – 会有阻力，但解释是为了自己的利益。
- unit testing！ 它伤害了，因为你只是想完成它，但是从长远来看，这将会节省你的时间。
- 使用错误跟踪 – Bugzilla或FogBugz，如果你能负担得起。
您需要与业主合作，并设定短期的中期和长期目标。 即使只通过电子邮件，你也会希望让他们知道进展。
你需要在你的工作日执行一些命令，否则你将永远无法完成任何事情（那些长期的目标）。
当你可以编码时，把你的一天分成几块，当你正在使用黑客来保持它时，在回复电子邮件等。
绝对设置一个错误跟踪器。 这可以帮助保持您的电子邮件清洁。 你甚至可以设置一个电子邮件地址来转发错误，以便以后分类。 这是很好的，因为错误记者最终会厌倦错误跟踪器，并且只是想给你发送错误。
编辑
而且正如lod3n所说，源代码pipe理，但是你已经使用它了！
去过也做过。
规划极限编程这本书帮了很多忙。 我用卡在墙上的3×5卡。 这让我的老板了解到了我的进展，帮助了估计和计划，并使我保持正轨。 如果你的老板的期望是不切实际的，规划游戏会给你好的弹药。
正如其他人所说，unit testing可以帮助即使你是唯一的开发者。 我觉得TDD风格很有价值。
lod3n是绝对正确的源代码pipe理。
我以前用过XP风格的迭代; 你可能想build立一个积压的项目（甚至像电子表格或3×5卡简单），以及。
避免deathmarches。 坚持40小时，连续两周不加class。 花更多时间学习新技能 – 不仅仅是技术，而是原则和最佳实践。
有一个错误跟踪系统，既有缺陷又有新function。 不要依赖你的记忆。
持续集成和自动构build甚至可以帮助单个开发人员。
不能强调足够的源代码pipe理的build议。
我决定不需要unit testing，因为我可以自动进行function/集成testing ：因为增量开发不需要在集成之前进行testing。
这听起来很疯狂，因为我喜欢sprint和backlogs的概念，所以我使用scrum。 这使得更容易设定现实的目标。 当然，Scrum的主人和团队的想法是你所有的，但是如果你正在外部项目中工作，那么你可能会挑选一个额外的团队成员来处理你的积压工作。 也许我只是喜欢积压。 有了Scrum，你将需要有人成为产品经理来谈论产品的function。 版本控制是必须的，可能应该实施b4，甚至担心软件开发过程。 我曾在一家从2个开发商开始的公司工作，一年到了12个。 我们从没有版本控制和低编码标准开始。 你需要做的改变将是渐进的，所以不要急于做一个180.设定一个目标，改变一个月的事情，并find你的改变的支持者，使事情顺利。
以及其他人的build议我会说，如果你对资源紧张，但有更多的发言权，你应该好好利用现成的和开源的产品和库。 这利用了别人的努力，节省了你的时间，确保你的代码基础不会变得太深奥，并增加了你的技能，所以你最终不会成为别无用处的专家。
首先，让我们区分开发过程和最佳实践。 像源代码控制，缺陷跟踪，unit testing等最佳实践是给定的。
然后是实际的开发过程。 我总是build议有一个stream程，不pipe团队是小团队还是大团队。 诀窍是find正确的过程。 你现在有一个过程 – 这只是一个临时过程，对你来说似乎没有太好的工作。 你很less可以采取一个教科书的发展过程，并直接应用它。 你需要做的是根据你的公司需求和文化量身定做。 看看尽可能多的开发范例，并尝试find一个很合适的东西，然后开始将它们塑造成您的需求。 您可能不得不尝试一些不同的stream程。 也许个人软件过程是一个很好的开始过程，也许是一个敏捷的过程，一个RUP的变种？ 你有很多select，开始尝试。
您也将不得不与其他组织一起工作 – 他们需要成为stream程的一部分。 你可能是唯一的开发人员，但是开发过程涉及的不仅仅是开发人员，还涉及到任何对产品有发言权和影响力的人。
这可能不是一个具体的答案，但我的观点是你需要某种程序。 所以开始研究他们，并尝试出来，塑造他们到你的需求，直到你有一些工作。
