我正在搬到一家新公司，在那里我将担任项目经理/开发人员/测试人员/发布管理等......我所从事的项目。基本上我就是一切。只要您交付产品，编程经理就不关心您的工作。所以，我需要开发我将如何管理我的项目。我还需要遵循一些方法，以便我不会学习坏习惯。
那么，基本上我应该使用什么样的方法？是否有一些资源我可能会考虑我将要进入的情况？我应该采用敏捷还是scrum？这些项目相当小。
截至目前，这是我计划做事的方式。请评论以下任何一项。
答案 0 :(得分：3)
我认为进入一家新公司并尝试实施开发方法“x”将是非常具有破坏性的，而无需先了解您当前管理的人员如何开发软件和交付项目。
你不能期望作为一名新经理走进去，并告诉从事这项工作的人明天他们所做的事情都是不同的，因为你这么说。
你将需要看看他们现在正在做什么，什么行不通，什么行不通，然后一旦你从你将要管理的人那里获得一点信任和尊重，并看到他们喜欢你的工作方式就可以了开始指出你认为这些洞在他们正在做什么的地方
理想情况下，您应该帮助他们得出他们需要过程'a'或过程'b'的结论。如果他们感觉到所有权及其自下而上的流程开发，那么您可能有机会被他们所遵循。新流程的自上而下的法令（现在，无论你选择何种方法，你的福音传播者有多么好），成功的可能性很小。
答案 1 :(得分：2)
这可能听起来有些陈词滥调，但是，根据我的经验来看，像你这样的情况以及我从学术界学到的东西，选择一种方法论非常困难 - 最大的两个问题是，你无法真正评估一种方法论在您使用它并获得经验之前是合适的，并且成功使用方法很大程度上取决于您和您的周围环境 - 仅仅因为您的老板是不干涉的，其他员工喜欢什么？他们之前是否因为IT项目不佳而被烧毁，IT的平均能力/接受程度是多少？
根据我在小团队中工作的经验;
线性方法论（SSADM等）
<强> 优点
<强> 缺点
迭代方法（RAD，UP）
<强> 优点
<强> 缺点
这对您有何影响？这取决于你觉得你可以像这样管理自己的方式（你以前有过这样的独立开发经验吗？） - 我个人发现一旦失去兴趣就很难坚持严格的方法。
虽然你提到你的管理层非常放手 - 这实际上可能是一个问题 - 如果没有人在监督中发挥作用 - 自我激励可能会下降而且我发现不干涉的人往往会更加沮丧谚语击中了粉丝！
你提到你不想养成坏习惯，听起来你可能适合采用更加严格的方法 - 所以你可能会找到我经常使用的方法，也很好。 OpenUP是一种迭代的，但有适度记录的方法，顶部的樱桃意味着你可以根据自己的需要定制方法 - 例如，开箱即用它对一个人乐队来说太重量级了 - 但它确实有合理的建议。
<强>要求
我无法强调尽可能多地记录并保留一个好的版本控制系统（即使这意味着你创建了一个新版本的word文档，每次重大更改）。
拥抱'敏捷'分析方法 - 白板是你的朋友。
如果能够有时间与最终用户一起使用，还可以考虑使用快速原型制作工具
设计＆amp;实施
我不得不说这完全取决于您的工具集/平台。只需使用您熟悉的工具即可。并使用Source Control。
<强>测试
如果可以获得开发和实时系统，那么如果您正在进行迭代操作，在开发过程中将已交付的代码部分推送到实时系统中，则更为重要。
<强> UAT
一个雷区，你需要确保你不会被“这个按钮是1个像素太远到正确”的问题所困扰，并专注于核心问题，优先考虑他们将采取的复杂性和时间修复。
而我的最后一块 - 每个人都讨厌它，每个人都应该这样做，每个人都说他们会，没有人会这样做 - 计划。如果我的计划更好，每次验尸。
答案 2 :(得分：1)
我想知道您是否需要使用自己的全新策略进入新公司，或者如果您现在可以使用他们正在做的任何事情来感受这个地方。从那里，你可以保持有效的方法并改变效率低下的方法。
这是一个资源，可以帮助您记住您可以使用的不同Software Development Methodologies。
答案 3 :(得分：1)
如果你拒绝承担这些项目会更好。因为当你是一个项目的一切，它是一项任务，不能被视为一个项目，它不需要一个PM。在另一方面，PM应该具备识别项目正确流程的知识和能力，而您目前还没有这个流程。所以对任何一方都没有好处。
答案 4 :(得分：0)
您提出的是瀑布计划。周围有足够的线程可以教会你为什么大多数组织在过去几年中已经远离它。
这是另一个想法。您尝试实施一种方法来承担所有角色（PM，BA，开发人员，QA，支持，发布），这种方法必然会失败。你真的不能做所有这些工作。那天没有足够的时间。嘿，我知道，作为一个团队领导，我让人们每天都把我拉向所有这些方向:)
此外，即使你可以做所有这些，你也无法完成所有这些。由于某种原因，它们是独立的角色，它们各自提供相互制衡。例如，作为开发人员，您最终会选择快捷方式，而您将无法作为分析师进行验证。作为QA，您只需检查您开发的应用程序的路径。坦率地说，如果你是一名开发人员，那么除了开发之外，你将会匆匆忙忙地完成所有事情，因为它很蠢。
如果他们只雇用一名技术人员，我真的会质疑公司的承诺。
答案 5 :(得分：0)
大多数敏捷流程适用于从事项目工作的小团队 - 似乎您将成为一个单独的团队......因此，您需要为此选择一种方法。为了取得成功，我强烈建议：
答案 6 :(得分：0)
如果您的项目很小，请坚持使用敏捷方法。由于您正在开发，因此您可以与客户进行持续的互动。显示你的工作，从他那里得到结果。大多数时候他们会建议在下一个冲刺中给出的小改动。
Agile在其ONE MAN节目中的主要好处是
与客户持续互动。
明白他想要的东西。
固定时间表，没有延迟，因为冲刺会很小。
您的互动不会产生任何歧义。你可以用更好的方法来说服为什么根据情况也无法做到。
没有繁忙的截止日期。