It is not really the case that any methodologies are specifically geared towards immature development teams per se. However if there is a characteristic of a methodology that would be beneficial for inexperienced developers it would be "well defined process".
The reason for the disclaimer ("requires a mature development team"), and this is nearly always applied to Agile methodologies, is that they require discipline and experience (which can only be gained from working on projects and learning from mistakes) to choose the right steps and make the right choices. Mature (read: experienced) developers know when it is safe (and not safe) to cut corners that inexperienced developers might do recklessly at every turn anyway. Also experienced developers have better intuitions and make better first choices, and know how to refactor designs and code properly when required.
To recast a famous quote from Bjarne Stroustrup into matching methodologies to (in)experienced teams, you might get: "Unleash an experienced team on a methodology that allows great flexibility and they might well shot themselves in the foot, unleash an inexperienced team on the same methodology and they'll probably blow their leg off". (Apologies to Bjarne, and anyone offended by the thought of leg injuries:)
It helps to have someone who is familiar with methodologies who can pick and choose what to add when. Trying to through a full blown methodology at an inexperienced team will likely overwhelm the team. Assigning someone senior to own the process would be a good idea.
I would start with version control and continuos build processes first. These will help identify if other changes break code. Automated testing tied to the build process would be a close second. Choosing what to build and when is also critical.
Throughout all of this communication about what is working and what is not should be occuring. Change what doesn't work, and continue adding.
The tough part is to produce stuff while this is happening.
If you have code to maintain, you may want to start with a small team working on new code to develop the methodology, and spread it to the team.
The methodology should drive getting the right information to the right person when it is needed. If the methodology is getting in the way of generating working code address the problem.
Reveiw the waterfall methodologies for things that need to be considered. Review the agile methodologies for how to consider things at the right time.
I can only advise you to set the environment, start working, and your team will adjust to the chosen methodologies. Create small release cycles, and adjust the chosen methodology at the beginning of every new release cycle.
Introducing code/design reviews can be a very valuable first step. It (if introduced correctly) can develop team bonding; can lead to "egoless" programming; lead to sharing of knowledge and learning; and picking up errors early in the process, when enthusiasm can lead to major pitfalls. Like @BillThor I think version control is valuable, but would suggest that teams generally need to experience the need for it before they will whole heartedly adopt it, and that this occurs only after they have had a versioning caused problem. The element that is useful for my answer, @Bill's and @Peter's is a capacity to have mentoring available. This (ideally) would be the role of a manager with development experience, or a senior developer.
发布评论
评论（4）
我的 0.02 美元
事实上，并不是任何方法都是专门针对不成熟的开发团队本身的。然而，如果方法论有一个对缺乏经验的开发人员有益的特征，那么它就是“明确定义的流程”。
免责声明（“需要一个成熟的开发团队”）的原因（这几乎总是适用于敏捷方法论）是，它们需要纪律和经验（这只能从项目工作和从错误中学习中获得）来选择正确的步骤并做出正确的选择。成熟（即：经验丰富）的开发人员知道什么时候可以安全（而不安全）地走捷径，而缺乏经验的开发人员可能会在每个环节都鲁莽行事。经验丰富的开发人员也有更好的直觉并做出更好的第一选择，并且知道如何在需要时正确重构设计和代码。
要将 Bjarne Stroustrup 的一句名言改写为与经验丰富的团队相匹配的方法，您可能会得到：“让一个经验丰富的团队采用一种允许极大灵活性的方法，他们很可能会搬起石头砸自己的脚，而让一个经验不足的团队采用一种方法，那么他们很可能会搬起石头砸自己的脚。同样的方法，他们可能会打断他们的腿”。
（向 Bjarne 以及任何因腿部受伤的想法而冒犯的人道歉：）
My $0.02
It is not really the case that any methodologies are specifically geared towards immature development teams per se. However if there is a characteristic of a methodology that would be beneficial for inexperienced developers it would be "well defined process".
The reason for the disclaimer ("requires a mature development team"), and this is nearly always applied to Agile methodologies, is that they require discipline and experience (which can only be gained from working on projects and learning from mistakes) to choose the right steps and make the right choices. Mature (read: experienced) developers know when it is safe (and not safe) to cut corners that inexperienced developers might do recklessly at every turn anyway. Also experienced developers have better intuitions and make better first choices, and know how to refactor designs and code properly when required.
To recast a famous quote from Bjarne Stroustrup into matching methodologies to (in)experienced teams, you might get: "Unleash an experienced team on a methodology that allows great flexibility and they might well shot themselves in the foot, unleash an inexperienced team on the same methodology and they'll probably blow their leg off".
(Apologies to Bjarne, and anyone offended by the thought of leg injuries:)
拥有熟悉方法论的人可以选择何时添加内容会很有帮助。尝试在缺乏经验的团队中采用完整的方法可能会让团队不知所措。指派一位资深人士来负责该流程将是一个好主意。
我会首先从版本控制和持续构建流程开始。这些将有助于确定其他更改是否会破坏代码。与构建过程相关的自动化测试将紧随其后。选择构建什么以及何时构建也很重要。
在所有这些关于什么是有效的、什么是不应该发生的沟通中。改变不起作用的部分，然后继续添加。
困难的部分是在这种情况发生时生产东西。
如果您有代码需要维护，您可能希望从一个致力于新代码的小团队开始，以开发该方法，并将其传播给团队。
该方法应该推动在需要时向正确的人提供正确的信息。如果该方法妨碍了生成工作代码，请解决该问题。
检查瀑布方法中需要考虑的事情。查看敏捷方法论，了解如何在正确的时间考虑事情。
It helps to have someone who is familiar with methodologies who can pick and choose what to add when. Trying to through a full blown methodology at an inexperienced team will likely overwhelm the team. Assigning someone senior to own the process would be a good idea.
I would start with version control and continuos build processes first. These will help identify if other changes break code. Automated testing tied to the build process would be a close second. Choosing what to build and when is also critical.
Throughout all of this communication about what is working and what is not should be occuring. Change what doesn't work, and continue adding.
The tough part is to produce stuff while this is happening.
If you have code to maintain, you may want to start with a small team working on new code to develop the methodology, and spread it to the team.
The methodology should drive getting the right information to the right person when it is needed. If the methodology is getting in the way of generating working code address the problem.
Reveiw the waterfall methodologies for things that need to be considered. Review the agile methodologies for how to consider things at the right time.
我只能建议您设置环境，开始工作，您的团队将适应所选的方法。创建小型发布周期，并在每个新发布周期开始时调整所选方法。
I can only advise you to set the environment, start working, and your team will adjust to the chosen methodologies. Create small release cycles, and adjust the chosen methodology at the beginning of every new release cycle.
引入代码/设计审查可能是非常有价值的第一步。它（如果正确引入）可以培养团队凝聚力；可以导致“无我”编程；导致知识共享和学习；并在过程的早期发现错误，此时热情可能会导致重大陷阱。就像@BillThor一样，我认为版本控制很有价值，但建议团队通常需要先体验一下它的需要，然后才会全心全意地采用它，并且只有在他们遇到版本控制引起的问题之后才会发生这种情况。 @Bill 和 @Peter 对我的回答有用的元素是获得指导的能力。 （理想情况下）这将是具有开发经验的经理或高级开发人员的角色。
Introducing code/design reviews can be a very valuable first step. It (if introduced correctly) can develop team bonding; can lead to "egoless" programming; lead to sharing of knowledge and learning; and picking up errors early in the process, when enthusiasm can lead to major pitfalls. Like @BillThor I think version control is valuable, but would suggest that teams generally need to experience the need for it before they will whole heartedly adopt it, and that this occurs only after they have had a versioning caused problem. The element that is useful for my answer, @Bill's and @Peter's is a capacity to have mentoring available. This (ideally) would be the role of a manager with development experience, or a senior developer.