在学习软件方法论时，我经常看到类似于“这种方法需要成熟的开发团队”的免责声明。
有哪些开发方法论是专门针对不成熟的开发团队的？ 我认为这是大多数团队应该开始的地方。
让我们将不成熟的团队定义为那些成员之前没有共事过，在未知环境中工作（即新公司），并且尚未定义其流程和控制的团队。
4个回答
7
我的看法
并没有哪种方法论是专门针对不成熟的开发团队的。然而，如果一个方法论具有对于经验不足的开发者有益的特点，那就是“明确定义的流程”。
免责声明（“需要成熟的开发团队”）的原因是，这几乎总是适用于敏捷方法论，因为它们需要纪律和经验（只能通过从项目中学习并从错误中吸取教训来获得），以选择正确的步骤并做出正确的选择。成熟的（即：有经验的）开发人员知道何时可以（不可以）缩短时间，而经验不足的开发人员可能会在每个转折点上鲁莽地削减时间。此外，有经验的开发人员具有更好的直觉，并作出更好的第一选择，并且知道在需要时如何适当地重构设计和代码。
重新解释Bjarne Stroustrup的一句名言，将方法论与（不）有经验的团队相匹配，你可能会得到这样的结果：“让一支经验丰富的团队使用一种允许极大灵活性的方法论，他们可能会自己射脚，让一支经验不足的团队使用同样的方法论，他们很可能会把自己的腿炸掉。”（对Bjarne和任何被腿部伤害想法冒犯的人表示歉意:)
- Peter G. McDonald
3
+1 个好引用。让我笑了。谢谢 :) - BЈовић
一个“明确定义的流程”会不会对一个没有纪律的团队来说规则太多而难以应对呢？也许定义较为松散且规则较少比较好。我只是想引发一下思考。明确定义的流程可能是个好主意，特别是如果它能最大限度地减少个人工作的范围。我认为需要很高的成熟度才能做好所有的工作，但大多数人只会精通一种。例如，开发人员应该专注于构建软件，而不是优先考虑未来的增强或完成 TPS 报告。流程应该支持这种聚焦。 - Mike M. Lin
那些经验较少的人可能无法处理模糊不清的情况。他们需要在开始时有一个具体的方法，然后再进行调整。 - JeffO
2
有人熟悉方法论并能够挑选添加什么是很有帮助的。试图向一个经验不足的团队推行完整的方法论可能会使团队感到不知所措。指派一位资深人员负责这个过程是个好主意。
我会先从版本控制和持续构建流程开始。这些将有助于确定其他更改是否破坏了代码。与构建流程相关联的自动化测试将是紧随其后的选择。选择何时构建以及构建什么也非常关键。
在所有这些过程中，应该进行关于工作情况的沟通。改变不起作用的东西，并继续添加新的内容。
艰难的部分是在此期间生产出东西。
如果您需要维护代码，您可能希望从小团队开始，让他们开发新代码来制定方法论，并将其传播给整个团队。
方法论应该推动在需要时将正确的信息传递给正确的人。如果方法论妨碍生成可工作的代码，请解决问题。
审查瀑布式方法论以考虑需要考虑的事项。审查敏捷方法论以了解如何在正确的时间考虑事项。
- BillThor
1
很好的回答。非常实用。 - LeWoody
2
我只能建议您设置环境，开始工作，您的团队将适应所选择的方法。创建小的发布周期，并在每个新的发布周期开始时调整所选择的方法。
- BЈовић
1
1不断改进。我喜欢它。 - Mike M. Lin
0
引入代码/设计审查可能是非常有价值的第一步。它（如果正确引入）可以发展团队凝聚力；可以导致“无自我”编程；促进知识共享和学习；并在过程早期发现错误，当热情可以导致重大陷阱时。像@BillThor一样，我认为版本控制很有价值，但建议团队通常需要经历对其的需求才会全心全意地采用它，并且只有在他们遇到版本控制引起的问题之后才会出现这种情况。对于我的答案、@Bill和@Peter有用的元素是可提供指导的能力。这（理想情况下）应该是一个具有开发经验的经理或高级开发人员的角色。
- Chris Walton
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接