agile - 不成熟团队的开发方法

Question

在研究软件方法论时，我经常看到类似“这种方法论需要成熟的开发团队”之类的免责声明。

哪些开发方法专门针对不成熟的开发团队？ 我认为这是大多数团队应该开始的地方。

让我们将一个不成熟的团队定义为一个团队，其成员以前没有一起工作过，在一个未知的环境（即新公司）中工作，并且还没有定义他们的流程和控制。

Answer 1

我的 0.02 美元

并非任何方法都专门针对不成熟的开发团队本身。但是，如果一种方法的特征对没有经验的开发人员有益，那将是“定义明确的过程”。

免责声明（“需要一个成熟的开发团队”）的原因，这几乎总是适用于敏捷方法，是他们需要纪律和经验（只能从项目工作和从错误中吸取教训）来选择正确的步骤并做出正确的选择。成熟（阅读：有经验的）开发人员知道什么时候可以安全（而不是不安全）偷工减料，而没有经验的开发人员可能会在每一个转折点上不计后果地走捷径。经验丰富的开发人员也有更好的直觉并做出更好的第一选择，并且知道如何在需要时正确重构设计和代码。

将 Bjarne Stroustrup 的一句名言改写为与经验丰富的团队相匹配的方法论，你可能会得到：“让经验丰富的团队在方法论上发挥极大的灵活性，他们很可能会自责，让缺乏经验的团队在同样的方法，他们可能会吹掉他们的腿”。（向 Bjarne 道歉，任何因腿部受伤而感到冒犯的人：）

Answer 2

我只能建议您设置环境，开始工作，您的团队将适应所选的方法。创建小型发布周期，并在每个新发布周期开始时调整所选方法。

Answer 3

让熟悉方法的人能够挑选和选择何时添加什么是有帮助的。在一个缺乏经验的团队中尝试使用完整的方法可能会使团队不堪重负。指派一位资深人士负责该流程将是一个好主意。

我会先从版本控制和持续构建过程开始。这些将有助于确定其他更改是否会破坏代码。与构建过程相关的自动化测试将紧随其后。选择构建什么以及何时构建也很关键。

在所有这些关于什么是有效的和什么不应该发生的沟通中。更改不起作用的内容，然后继续添加。

困难的部分是在这种情况下生产东西。

如果您有代码需要维护，您可能希望从一个小团队开始，开发新代码以开发方法，并将其传播给团队。

该方法应推动在需要时将正确的信息提供给正确的人。如果该方法妨碍生成工作代码，请解决问题。

回顾瀑布方法，了解需要考虑的事情。查看敏捷方法，了解如何在正确的时间考虑事物。

Answer 4

引入代码/设计审查可能是非常有价值的第一步。它（如果引入正确）可以发展团队凝聚力；可能导致“无我”编程；导致知识和学习的共享；并在过程的早期发现错误，因为热情可能会导致重大陷阱。与@BillThor 一样，我认为版本控制很有价值，但建议团队通常需要先体验对它的需求，然后才会全心全意地采用它，并且只有在他们遇到版本控制引起的问题之后才会发生这种情况。对我的回答有用的元素，@Bill's 和@Peter's 是提供指导的能力。这（理想情况下）将是具有开发经验的经理或高级开发人员的角色。