不成熟团队的发展方法

Question

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

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

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

Answer 1

我的$ 0.02

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

免责声明的原因（“需要一个成熟的开发团队”），这几乎总是适用于敏捷方法论，它们需要学科和经验（只能通过项目工作和从错误中学习）选择正确的步骤并做出正确的选择。成熟（阅读：有经验的）开发人员知道什么时候安全（而且不安全）偷工减料，没有经验的开发人员可能会在任何时候肆无忌惮地做。经验丰富的开发人员也有更好的直觉，做出更好的首选，并且知道如何在需要时对设计和代码进行重构。

要将Bjarne Stroustrup的名言改编成与经验丰富的团队匹配的方法，你可能会得到：“释放一个经验丰富的团队，使其具有很大的灵活性，他们可能会在脚下开枪，释放出一个没有经验的人团队采用相同的方法，他们可能会把他们的腿断开“。 （向Bjarne道歉，以及任何因腿部受伤而受到冒犯的人：）

Answer 2

让某些熟悉方法论的人可以选择在何时添加内容。尝试通过一个没有经验的团队的完整方法可能会压倒团队。指派一位资深人士拥有这个过程将是一个好主意。

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

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

困难的部分是在发生这种情况时制作东西。

如果您需要维护代码，您可能需要从一个小团队开始研究新代码，然后将其传播给团队。

该方法应该在需要时将正确的信息传递给合适的人。如果该方法妨碍了生成工作代码来解决问题。

了解需要考虑的事物的瀑布式方法。查看敏捷方法，了解如何在合适的时间考虑事项。

Answer 3

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

Answer 4

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