blocks|key|4128491|text|最重要的部分是在适当的地方有一个反思/回顾机制，以促进持续改进。从一些流程模型开始，并随着时间的推移根据您的需求进行演变。停止做不值得做的事情。继续做能带来高价值的事情。尝试你认为有价值的新事物或解决特定问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4128492|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|4128514|text|你的问题是什么？是哪种方法最适合呢？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4128515|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

What is you question ? Is it which methodology would be most suitable ?

blocks|key|4128656|text|你不会从一个正式的系统对这种规模的团队施加的所有开销中获得太多好处。相反，尝试使用a+good+management+technique来确保每个人都在互相监听，并且删除了块。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4128657|entityMap|0|LINK|mutability|MUTABLE|url|http://www.randsinrepose.com/archives/2009/06/01/a_deep_breath.html^0|15|R|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You don't get much benefit from all the overhead that a formallised system will impose with that size of team. Instead, try <a href="http://www.randsinrepose.com/archives/2009/06/01/a_deep_breath.html" rel="nofollow noreferrer">a good management technique</a> to make sure everyone is listening to each other and blocks are removed.

blocks|key|19309|text|我认为Scrum适用于中小型团队。与XP相比，它省略了一些细节，因此您可以借鉴XP或做一些有意义的事情。无论您选择哪种方法，都必须考虑chickens(customers/managers/stakeholder/domain专家的角色。有时你必须自己扮演这些角色，但许多敏捷方法是有效的，因为有外部的pace汽车，具有扎根的领域知识。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|19310|其他关键方面是团队之间的沟通水平和某种形式的质量保证机制。如果你们不在同一栋楼里，就很难进行结对编程。Scrum试图在sprint周期内接受一个特性，而XP则试图使用单元测试、代码审查和持续集成在一天内集成该特性。|19311|​|19312|📷|atomic|19313|19314|*)+Sprint可以从15天到30天不等。|19315|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Scrum_%2528development%2529|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/453c02592154d5847bb7e56a202a443b.png|imageAlt^0|3|5|0|0|0|0|0|1|1|0|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|16|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|17|8|@]|9|@$A|18|B|19|1|1A]]|C|$]]|$1|K|3|G|5|6|7|1B|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1C|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]|V|$5|W|R|X|C|$Y|Z|10|-4]]]]

I think <a href="http://en.wikipedia.org/wiki/Scrum_%28development%29" rel="nofollow noreferrer">Scrum</a> 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.

<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Scrum_process.svg/400px-Scrum_process.svg.png" alt="Scrum process">

*) Sprint can range from 15-30 days.

blocks|key|4128851|text|我曾经和一个这样的团队合作过，甚至更大的团队，在两个共享一些公共库的团队中。Scrum为我们工作得很好。现在我和一个有6个成员的团队一起工作，我们使用XP，我认为它也可以工作。第一个团队开发了一个产品，来自“外层空间”的影响并不是那么大。因此，更长的迭代运行得很好。不，我们开发一个客户项目，因此更短的发布周期对我们更好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4128852|但SCRUM和XP不止于此。现在我们使用TDD和配对编程(这两种方法都来自XP世界)。我们还有更像SCRUM的日常站立会议。因此，我们采用XP和SCRUM来为我们的项目和我们的情况工作。|4128853|我会从短周期(1周)和这个周期的回顾开始。在你的团队中采用一种新的方法需要一些时间，但如果成员愿意学习和改变，它就会奏效。|4128854|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|910963|text|Scrum和看板都是真正的流程“骨架”。两者都不是特定于软件开发的。Scrum由软件开发组织推广，但定位为通用管理技术，而不是软件项目管理技术。看板从制造中脱颖而出，并已适应软件开发，最初由维护团队进行。Scrum和Kanban的目标都是通过执行该工作的团队来管理工作单元的流程，测量工作流程的速度，以便能够做出更准确的估计，并使瓶颈高度可见，以便解决这些瓶颈。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|910964|因为两者都不是特定于软件开发的，所以使用Scrum和看板的团队将软件开发实践添加到过程中，以帮助他们以增量和迭代的方式发布和改进软件。大多数团队，无论是在Scrum还是看板过程中工作，都采用XP的技术实践和Crystal的reflective实践。|910965|XP基本上是应用于单个团队的Scrum，以及关于什么使代码“高质量”以及程序员如何实现高质量的指导方针。Crystal+Clear也适用于位于同一地点的小型团队，但它在编程实践方面更加灵活，尽管它也推荐XP实践(描述该过程的书非常优秀，并且充满了宝贵的建议，无论您决定采用哪种过程)。Scrum团队通常也采用Crystal的反思实践:定期的“心跳”回顾和每个重大里程碑之后的更大规模的回顾。看板需要持续的反思和改进，但一些团队也使用回顾。|910966|如果您想要在小型编程团队中开始应用增量/迭代过程，那么我认为XP是一个很好的开始，因为它为技术能力设置了相当高的标准，并且有很好的文档记录。连续流和看板如何最好地应用于软件开发行业的不同领域，在看板-开发邮件列表和其他地方仍然存在争论。|910967|我还建议定期进行回顾，以改进流程并使其适应您的特定情况。|910968|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

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.

We have a four person development team that is in need of a formalized project management system. I have a general understanding of Scrum and Kanban but it's hard to truly understand until it's been tried. We don't have the luxury of trying one for a few weeks and then switching to another so I was hoping that someone out there in a similar situation might have thoughts on which worked better for them and why. Also, any other systems for managing development that worked would be great to hear about.

Another note: there's the possibility of the team growing, of course, so we would need a system that scaled well. 

Yet another note: We work on three separate software applications in Windows all of which are based on a central library which we also wrote (so i guess you could say four projects)

Scrum, Kanban or Other for 4 person dev team

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们有一个四人开发团队，需要一个正式的项目管理系统。我对Scrum和看板有一个大致的了解，但在尝试之前很难真正理解它。我们不能奢侈地尝试几个星期，然后切换到另一个，所以我希望有类似情况的人可能会想到哪个对他们更好，为什么。此外，任何其他有效的管理开发系统将是伟大的听到。另一个注意事项:当然，团队有可能会增长，所以我们需...

问Scrum、看板或其他4人开发团队
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Scrum、看板或其他4人开发团队EN