我们有一个四人开发团队,需要一个正式的项目管理系统。我对 Scrum 和看板有一个大致的了解,但在尝试之前很难真正理解。我们没有奢侈的尝试几个星期然后切换到另一个,所以我希望有类似情况的人可能会思考哪个对他们更有效以及为什么。此外,任何其他有效的开发管理系统都会很高兴听到。
另一个注意事项:当然,团队有增长的可能性,所以我们需要一个可扩展的系统。
另一个注意事项:我们在 Windows 中开发三个独立的软件应用程序,所有这些应用程序都基于我们也编写的中央库(所以我猜你可以说四个项目)
我们有一个四人开发团队,需要一个正式的项目管理系统。我对 Scrum 和看板有一个大致的了解,但在尝试之前很难真正理解。我们没有奢侈的尝试几个星期然后切换到另一个,所以我希望有类似情况的人可能会思考哪个对他们更有效以及为什么。此外,任何其他有效的开发管理系统都会很高兴听到。
另一个注意事项:当然,团队有增长的可能性,所以我们需要一个可扩展的系统。
另一个注意事项:我们在 Windows 中开发三个独立的软件应用程序,所有这些应用程序都基于我们也编写的中央库(所以我猜你可以说四个项目)
Scrum 和看板都是真正的流程“骨架”。两者都不是特定于软件开发的。Scrum 由软件开发组织推广,但被定位为通用管理技术而不是软件项目管理技术。看板起源于制造业,最初由维护团队适应软件开发。Scrum 和看板都旨在通过执行该工作的团队来管理工作单元的流程,衡量工作流程的速度以便可以越来越准确地进行估算,并使瓶颈高度可见,以便可以解决它们。
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.
如果您想在小型编程团队中开始应用增量/迭代过程,那么我认为 XP 是一个很好的开始,因为它为技术能力设置了相当高的标准,并且有很好的文档记录。持续流和看板如何最好地应用于软件开发行业的不同领域,仍在看板开发邮件列表和其他地方进行辩论。
我建议还进行定期回顾以改进流程并使其适应您的具体情况。
最重要的部分是建立一个有助于持续改进的反思/回顾机制。从一些流程模型开始,并随着时间的推移根据您的需要对其进行改进。停止做不值得做的事情。继续做能带来高价值的事情。尝试您认为有价值或解决特定问题的新事物。
我认为Scrum适用于中小型团队。与 XP 相比,它省略了一些细节,因此您可以借鉴 XP 或做一些有意义的事情。无论您选择哪种方法,您都必须考虑小鸡(客户/经理/利益相关者/领域专家)的角色。有时您必须自己扮演角色,但许多敏捷方法之所以奏效,是因为有具有该领域基础知识的外部节奏汽车。
其他关键方面是团队之间的沟通水平和某种形式的质量保证机制。如果您不在同一栋楼内,则很难进行结对编程。Scrum 试图在一个 sprint 周期内让一个特性被接受,而 XP 试图通过单元测试、代码审查和持续集成在一天之内集成这个特性。
*) Sprint 的时间范围为 15-30 天。
你有什么问题?哪种方法最合适?
您不会从正式系统对这种规模的团队强加的所有开销中获得太多好处。相反,请尝试一种良好的管理技术,以确保每个人都在互相倾听并消除障碍。
我曾与一个这样的团队合作过,甚至在两个共享一些公共库的团队中更大。Scrum 对我们很有效。现在我和一个有 6 名成员的团队一起工作,我们使用 XP,我认为它也很有效。第一个团队开发了一个产品,来自“外太空”的影响并没有那么大。所以更长的迭代工作得很好。不,我们开发客户项目,因此更短的发布周期对我们来说更好。
但 SCRUM 和 XP 远不止这些。现在我们使用 TDD 和 Pair-Programming(两者都来自 XP 世界)。我们也有更像 SCRUM 的每日站立会议。所以我们使用 XP 和 SCRUM 来为我们的项目和我们的情况工作。
我将从短周期(1 周)和对这个周期的回顾开始。在您的团队中采用新方法需要一些时间,但如果成员愿意学习和改变,它会起作用。