由于两者都不是特定于软件开发的，因此使用 Scrum 和看板的团队将软件开发实践添加到流程中，以帮助他们增量、迭代地发布和改进软件。 大多数团队，无论是在 Scrum 还是看板流程中工作，都采用 XP 的技术实践和 Crystal 的反思实践。
XP 基本上是应用于单个团队的 Scrum 以及有关如何使代码“高质量”以及程序员如何实现这一目标的指南。 Crystal Clear 也适用于小型同地团队，但在编程实践方面更加灵活，尽管它也推荐 XP 实践（描述该过程的书非常出色，并且充满了宝贵的建议，无论您决定采用什么过程）。 Scrum 团队通常还采用 Crystal 的反思实践：定期进行“心跳”回顾，并在每个重大里程碑之后进行更大规模的回顾。 看板需要不断反思和改进，但有些团队也使用回顾。
如果您想开始在小型编程团队中应用增量/迭代流程，那么我认为 XP 是一个很好的起点，因为它为技术能力设置了相当高的标准，并且有很好的文档记录。 连续流和看板如何最好地应用于软件开发行业的不同领域仍在 kanban-dev 邮件列表和其他地方争论。
我还建议定期进行回顾，以改进流程并使其适应您的具体情况。
Both Scrum and Kanban are really process "skeletons". Neither is specific to software development. Scrum was popularised by software development organisations but is positioned as general management technique rather than a software project management technique. Kanban emerged from manufacturing and has been adapted to software development, initially by maintenance teams. Both Scrum and Kanban aim to manage the flow of units of work through the team that is doing that work, measure how fast work flows so that estimates can be made more and more accurately, and make bottlenecks highly visible so that they can be addressed.
Because neither is specific to software development, teams using Scrum and Kanban add software development practices to the process to help them incrementally and iteratively release and improve the software. Most teams, whether working within a Scrum or Kanban process, adopt the technical practices of XP and reflective practices of Crystal.
XP is basically Scrum applied to a single team plus guidelines about what makes code "high quality" and how programmers can achieve that. Crystal Clear also applies to small co-located teams but is more flexible about programming practices although it also recommends the XP practices (the book describing the process is excellent and full of invaluable advice, whatever process you decide to go with). Scrum teams also usually adopt the reflective practices of Crystal: regular "heart-beat" retrospectives and larger retrospectives after every major milestone. Kanban requires continual reflection and improvement but some teams use retrospectives too.
If you want to start applying an incremental/iterative process in a small programming team, then I think XP is a good process to start with because it sets the bar pretty high for technical capability and is very well documented. How continuous-flow and Kanban best applies to different areas of the software development industry is still being debated on the kanban-dev mailing list and elsewhere.
I would recommend also performing regular retrospectives to improve the process and adapt it to your specific situation.
The most important part is to have a reflection/retrospective mechanmism in place which facilitates continuous improvement. Start with some process model and evolve it over time for your needs. Stop doing things that are not worth doing. Keep on doing things that bring in high value. Try new things that you think could be valuable or address specific problems.
我认为 Scrum 适用于中小型团队。 与 XP 相比，它省略了一些细节，因此您可以借用 XP 或做一些有意义的事情。 无论您选择哪种方法，您都必须考虑鸡的角色（客户/经理/利益相关者/领域专家）角色。 有时您必须自己扮演这些角色，但许多敏捷方法之所以有效，是因为有具有该领域扎实知识的外部调速车。
其他关键方面是团队之间的沟通水平以及某种形式的质量保证机制。 如果你们不在同一栋大楼里，就很难进行结对编程。 Scrum 尝试在一个冲刺周期内让某个功能被接受，而 XP 尝试使用单元测试、代码审查和持续集成在一天内集成该功能。
*) Sprint 的范围可以是15-30 天。
I think Scrum works for small to medium team. Compared to XP it leaves out some details, so you can borrow from XP or do something that makes sense. Either methodology you pick, you have to consider the role of chickens(customers/managers/stakeholder/domain experts) role. Sometimes you have to play the roles yourself, but many agile methodologies work because there's external pace car with grounded knowledge of the domain.
Other key aspects are the communication level among your team and some form of quality assurance mechanism. It's hard to do pair programming if you are not located in the same building. Scrum tries to get a feature to acceptance within a sprint cycle, and XP tries to get the feature integrated within the day using unit tests, code review, and continuous integration.
You don't get much benefit from all the overhead that a formallised system will impose with that size of team. Instead, try a good management technique to make sure everyone is listening to each other and blocks are removed.
I've worked with a team of that sice and even bigger on two teams that shared some common libraries. Scrum worked well for us. Now I work with a team with 6 members and we use XP and I think it works as well. The first team developed a product and the influences from 'the outer space' were not that big. So longer iterations worked fine. No we develop a customer project and therefore shorter release cycles are better for us.
But SCRUM and XP are more than that. Now we use TDD and Pair-Programming (both more from the XP world). We also have daily standup meetings that are more SCRUM like. So we adoped XP and SCRUM to work for our project and our situation.
I would start with short cylces (1 week) and reviews of this cycle. It will take some time to adopt a new methodology in your team but if the members are willing to learn and change it will work.
发布评论
评论（6）
Scrum 和看板都是真正的流程“骨架”。 两者都不是特定于软件开发的。 Scrum 被软件开发组织所普及，但被定位为通用管理技术而不是软件项目管理技术。 看板诞生于制造业，并已适应软件开发，最初是由维护团队进行的。 Scrum 和看板的目标是通过执行该工作的团队来管理工作单元的流程，衡量工作流程的速度，以便可以越来越准确地进行估计，并使瓶颈高度可见，以便可以解决它们。
由于两者都不是特定于软件开发的，因此使用 Scrum 和看板的团队将软件开发实践添加到流程中，以帮助他们增量、迭代地发布和改进软件。 大多数团队，无论是在 Scrum 还是看板流程中工作，都采用 XP 的技术实践和 Crystal 的反思实践。
XP 基本上是应用于单个团队的 Scrum 以及有关如何使代码“高质量”以及程序员如何实现这一目标的指南。 Crystal Clear 也适用于小型同地团队，但在编程实践方面更加灵活，尽管它也推荐 XP 实践（描述该过程的书非常出色，并且充满了宝贵的建议，无论您决定采用什么过程）。 Scrum 团队通常还采用 Crystal 的反思实践：定期进行“心跳”回顾，并在每个重大里程碑之后进行更大规模的回顾。 看板需要不断反思和改进，但有些团队也使用回顾。
如果您想开始在小型编程团队中应用增量/迭代流程，那么我认为 XP 是一个很好的起点，因为它为技术能力设置了相当高的标准，并且有很好的文档记录。 连续流和看板如何最好地应用于软件开发行业的不同领域仍在 kanban-dev 邮件列表和其他地方争论。
我还建议定期进行回顾，以改进流程并使其适应您的具体情况。
Both Scrum and Kanban are really process "skeletons". Neither is specific to software development. Scrum was popularised by software development organisations but is positioned as general management technique rather than a software project management technique. Kanban emerged from manufacturing and has been adapted to software development, initially by maintenance teams. Both Scrum and Kanban aim to manage the flow of units of work through the team that is doing that work, measure how fast work flows so that estimates can be made more and more accurately, and make bottlenecks highly visible so that they can be addressed.
Because neither is specific to software development, teams using Scrum and Kanban add software development practices to the process to help them incrementally and iteratively release and improve the software. Most teams, whether working within a Scrum or Kanban process, adopt the technical practices of XP and reflective practices of Crystal.
XP is basically Scrum applied to a single team plus guidelines about what makes code "high quality" and how programmers can achieve that. Crystal Clear also applies to small co-located teams but is more flexible about programming practices although it also recommends the XP practices (the book describing the process is excellent and full of invaluable advice, whatever process you decide to go with). Scrum teams also usually adopt the reflective practices of Crystal: regular "heart-beat" retrospectives and larger retrospectives after every major milestone. Kanban requires continual reflection and improvement but some teams use retrospectives too.
If you want to start applying an incremental/iterative process in a small programming team, then I think XP is a good process to start with because it sets the bar pretty high for technical capability and is very well documented. How continuous-flow and Kanban best applies to different areas of the software development industry is still being debated on the kanban-dev mailing list and elsewhere.
I would recommend also performing regular retrospectives to improve the process and adapt it to your specific situation.
最重要的是要有一个反思/回顾机制，以促进持续改进。 从一些流程模型开始，并随着时间的推移对其进行改进以满足您的需求。 停止做那些不值得做的事情。 继续做能带来高价值的事情。 尝试您认为有价值的新事物或解决特定问题。
The most important part is to have a reflection/retrospective mechanmism in place which facilitates continuous improvement. Start with some process model and evolve it over time for your needs. Stop doing things that are not worth doing. Keep on doing things that bring in high value. Try new things that you think could be valuable or address specific problems.
我认为 Scrum 适用于中小型团队。 与 XP 相比，它省略了一些细节，因此您可以借用 XP 或做一些有意义的事情。 无论您选择哪种方法，您都必须考虑鸡的角色（客户/经理/利益相关者/领域专家）角色。 有时您必须自己扮演这些角色，但许多敏捷方法之所以有效，是因为有具有该领域扎实知识的外部调速车。
其他关键方面是团队之间的沟通水平以及某种形式的质量保证机制。 如果你们不在同一栋大楼里，就很难进行结对编程。 Scrum 尝试在一个冲刺周期内让某个功能被接受，而 XP 尝试使用单元测试、代码审查和持续集成在一天内集成该功能。
*) Sprint 的范围可以是15-30 天。
I think Scrum works for small to medium team. Compared to XP it leaves out some details, so you can borrow from XP or do something that makes sense. Either methodology you pick, you have to consider the role of chickens(customers/managers/stakeholder/domain experts) role. Sometimes you have to play the roles yourself, but many agile methodologies work because there's external pace car with grounded knowledge of the domain.
Other key aspects are the communication level among your team and some form of quality assurance mechanism. It's hard to do pair programming if you are not located in the same building. Scrum tries to get a feature to acceptance within a sprint cycle, and XP tries to get the feature integrated within the day using unit tests, code review, and continuous integration.
*) Sprint can range from 15-30 days.
你问什么问题？ 哪种方法最合适？
What is you question ? Is it which methodology would be most suitable ?
对于这种规模的团队来说，正式化的系统所带来的所有开销并没有给你带来太多好处。 相反，尝试良好的管理技巧来确保每个人都互相倾听，障碍就会被移除。
You don't get much benefit from all the overhead that a formallised system will impose with that size of team. Instead, try a good management technique to make sure everyone is listening to each other and blocks are removed.
我曾与那个地方的一个团队合作过，甚至在两个共享一些公共库的团队中工作过。 Scrum 对我们来说效果很好。 现在我和一个有 6 名成员的团队一起工作，我们使用 XP，我认为它也很有效。 第一个团队开发的产品，受“外太空”的影响并不大。 所以更长的迭代效果很好。 不，我们开发一个客户项目，因此较短的发布周期对我们来说更好。
但 SCRUM 和 XP 的意义远不止于此。 现在我们使用 TDD 和结对编程（两者都更多地来自 XP 世界）。 我们还有每天的站立会议，更像是 SCRUM。 因此，我们采用 XP 和 SCRUM 来适合我们的项目和我们的情况。
我会从短周期（1 周）开始，并对这个周期进行回顾。 在团队中采用新的方法需要一些时间，但如果成员愿意学习和改变，那么它就会起作用。
I've worked with a team of that sice and even bigger on two teams that shared some common libraries. Scrum worked well for us. Now I work with a team with 6 members and we use XP and I think it works as well. The first team developed a product and the influences from 'the outer space' were not that big. So longer iterations worked fine. No we develop a customer project and therefore shorter release cycles are better for us.
But SCRUM and XP are more than that. Now we use TDD and Pair-Programming (both more from the XP world). We also have daily standup meetings that are more SCRUM like. So we adoped XP and SCRUM to work for our project and our situation.
I would start with short cylces (1 week) and reviews of this cycle. It will take some time to adopt a new methodology in your team but if the members are willing to learn and change it will work.