敏捷开发模式kanban_敏捷 kanban 起源 - CSDN
  • 两种敏捷开发方式的工作流 敏捷开发时当今很流行的一种开发软件方式,接下来主要介绍一下两种主要的敏捷开发方式的工作流 Scrum flow 项目计划从定义backlog开始,即交付完成的产品时应该完成的用户需求列表。 产品...

    两种敏捷开发方式的工作流

    敏捷开发时当今很流行的一种开发软件方式,接下来主要介绍一下两种主要的敏捷开发方式的工作流

    Scrum flow

    项目计划从定义backlog开始,即交付完成的产品时应该完成的用户需求列表。

    • 产品 backlog - 列出团队主要的 “To Do” list。 产品的代办事项列表应该包括全部的特性和 bug 修复。以便在项目结束时确认已经完成。产品的代办列表需要在工作中按照新的需求或者发现的错误持续的更新。产品的负责人负责待办事项,使其与客户的反馈和建议以及团队的工作进度同步。一些Item的优先级应该被提升或下降,一些item应该根据需求的变化增加或者减少。
    • Sprint backlog - 包含在特定sprint中要完成的任务。sprint backlog的项目被选择为在sprint结束时交付一个完成的特性或组件。虽然sprint backlog也允许一定的灵活性和修改,但是sprint的目标应该保持不变,并且变更应该保持在最小。
    • Sprint goal or increment - 作为sprint结果交付的可用产品。通常,sprint以展示完成的特性或组件的演示结束。在这方面,一个重要的概念是“done”的定义,它指的是要将每个用户工作视为完整的。“done”的定义可能会根据用户的情况而有所不同:它可能包含多个任务,例如开发、测试、设计、文档和表示,还可能涉及不同的团队成员。

    每个sprint都从一个计划阶段开始,在下一个sprint中选择任务。对于计划阶段,整个团队通常都会到场,包括产品负责人和Scrum Master。团队决定在sprint结束时可以交付什么,并从产品backlog中选择相应的用户工作。通过这种方式,他们将sprint backlog放在一起。

    在sprint期间,团队每天开会进行“每日scrum”,讨论他们的进展以及可能遇到的任何障碍。每日scrum的目的是尽早发现问题,并快速找到解决方案,以免中断sprint流程。

    在sprint之后,涉众将审查完成的特性。在sprint评审期间,团队有机会收到关于他们工作的反馈,以及变更建议(如果有的话)。

    与此同时,团队开会进行sprint回顾,分析他们刚刚完成的sprint,并找到可以改进的地方。回顾之后,流程被重置,新的sprint从计划阶段开始。

    Kanban flow

    在 Kanban中,没有要求需要在一个确定的时间点完成一定数量的工作。相反,Kanban专注于平衡团队的当前正在进行的工作的能力。

    一个 Kanban 项目流程从一般的backlog开始,包含所有的应该完成的任务。每个团队成员从backlog中为自己挑选一个任务,并集中精力完成它。当任务完成时,成员选择下一个任务,以此类推,直到所有任务完成为止。待办事项列表的优先级是将最紧急的任务放在顶部,由团队首先处理。

    在Kanban中,重要的是在项目期间的任何时候,正在进行的工作量都不能超过团队的能力。为此目的,有可能根据现有的能力为任何类型的工作定一个限度。

    产品负责人可以尽可能频繁地设置和更改backlog中的优先级,因为backlog管理对团队的性能没有影响。团队只关心正在进行的工作,只有在当前任务完成后才返回到backlog。

    每个任务都沿着“To Do”—“Work in Progress”—“Done”路线进行。当然,Kanban也支持“完成”定义的概念,这是每个任务接受的标准。

    总而言之,我们可以说Scrum的主要区别在于它试图在指定的时间内完成预定的工作,而Kanban确保正在进行的工作永远不会超过设定的限制。

    如何选择

    如果你一直在等待这个问题的最终答案,我们可能会让你失望。到目前为止,我们希望已经成功地证明了这两种方法都有它们的优点,并且都可以帮助建立敏捷开发过程。然而,我们提供了一些指导方针,可以帮助您选择最适合您的团队的方法。

    使用 Scrim

    • 你可以相对容易地将工作划分为逻辑块,这些逻辑块可以在两周内完成。
    • 你需要对整个项目有高度的可预测性。Scrum专注于将sprint中的变更保持在最小。
    • 你的团队里有很多新成员。使用Scrum,如果需要的话,他们会更容易理解团队纪律并做出改进。

    使用 Kanban

    • 你期望项目中有很多频繁的变更。
    • 很难隔离能够在两周内交付的产品组件。
    • 你的团队纪律严明,可以信任他们会在没有严格截止日期的情况下安排他们的活动。
    展开全文
  • Kanban虽然有透明、限制WIP(在制品)和度量、提升工作流、PULL模式作为基本的特点,但这并不是说选择Kanban是因为Scrum不具备这些特点。应该说,两者都具备这些特点,只是在细节处各有侧重。Kanban和Scrum比较,在...

    Kanban虽然有透明、限制WIP(在制品)和度量、提升工作流、PULL模式作为基本的特点,但这并不是说选择Kanban是因为Scrum不具备这些特点。应该说,两者都具备这些特点,只是在细节处各有侧重。Kanban和Scrum比较,在团队组织、交付频率、流程管理等方面有以下的不同之处,了解这些区别,会方便我们选择是否用Kanban:

    展开全文
  • 敏捷开发模式的修炼之道 CSDN:请问你是如何接触到敏捷开发的?你如何理解敏捷开发? 黄勇:曾经我们开发项目都是采用传统的“瀑布式”流程进行开发,即需求、设计、开发、测试、上线等阶段,其中每个阶段都...

    敏捷开发模式的修炼之道

    CSDN:请问你是如何接触到敏捷开发的?你如何理解敏捷开发?

    黄勇:曾经我们开发项目都是采用传统的“瀑布式”流程进行开发,即需求、设计、开发、测试、上线等阶段,其中每个阶段都有明确的交付时间点,且每个阶段都依赖于它的上个阶段,一旦需求有变化,就会影响后续的每个阶段,项目管理存在一定的风险。为了避免这个风险,做到更好地拥抱变化,我们尝试使用了敏捷开发方法,最为典型的是 Scrum。我们参考Scrum 的流程结合自身的特点,总结了一套更容易落地的Scrum,后面我会跟大家讲到一些相关细节。

    我理解的敏捷开发实际上是一个轻量级的项目管理规范,因为我们可以将整个大的需求范围拆分成若干迭代周期,我们为这些迭代周期设置明确的里程碑,且评估完成这些功能需要花费的成本,更重要的是,每次迭代完成以后,我们会对本次迭代进行一个回顾,取其精华,去其糟粕,不断完善,持续改进。

    CSDN:你认为国内的敏捷开发何时能成为主流?敏捷开发的未来走向是什么?

    黄勇:我认为敏捷开发现在已经成为了主流,传统开发模式已经出现了明显的缺陷,随着互联网的发展,软件开发的节奏会越来越快,变化也会越来越频繁,需要我们能够快速地发现变化,并进行及时地调整。

    我认为敏捷开发的未来会变得更好,不仅仅在软件开发行业,而且可能会在其它行业里也会得到应用,因为从客户的角度来看,他们想要的是能通过最短的时间看到自己想要的东西,很多时候不做出一点东西出来,客户是没有任何想法的,所以需要将事情分解成多阶段,迭代完成每个阶段的里程碑,让客户满意,才是企业最大的收获。

    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法?

    黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我个人比较倾向于 Scrum。我理解的敏捷其实是一种思想,Scrum 是对让这个思想落地的一个参考。也就是说,我们大可不必完全拘泥于 Scrum 定义的规范,只需要参考它并结合自身的条件做适当调整即可。比如说,每日站会这个环节就非常重要,不管是放在每天上午,还是放在每天下午,总之最好要有固定的周期。此外,每次 Sprint(迭代)结束后除了有评审会以外,Scrum Master 不要忘记对本次 Sprint 做一个回顾与总结,哪些是本次迭代中做的好的地方,哪些是做的不好的,再对比上次迭代的的结论,哪些是有改进的,哪些是新的问题。

    Scrum 提供了三类角色,分别是:Product Owner(一般由产品经理担任)、Scrum Master(一般由开发经理担任)、Scrum Team(包括开发与测试人员),其中,Scrum Master 的角色至关重要,对项目的成败起决定性作用。

    阿里巴巴也在广泛使用 Scrum 敏捷开发模式,而且整个项目几十人都可以用 Scrum,只是首先需要将整个团队拆分成若干小团队,保证每个小团队按照 Scrum 进行操作,此外,再将每个小团队的 Scrum Master 召集在一起,再做一轮 Scrum,这就是所谓的 Scrum of Scrum。过程稍微复杂一点,但可以将敏捷用于更大的团队规模,并能保证敏捷的效果。

    CSDN:你认为Scrum Master 的角色至关重要,对项目的成败起决定性作用。那敏捷开发中由产品经理担任Scrum Master会有什么问题?

    黄勇:我个人不太建议由产品经理来担当Scrum Master,原因如下:

    1. Scrum Master 关注的是项目开发视角,而产品经理关注的是产品功能视角,两者关注的视角是不一样的。
    2. Scrum Master 需要有一定的技术开发功底,需要对开发工作量进行评估,也需要对技术实现进行评审,可能还会有一定的编码工作,而具有技术功底的产品经理毕竟太少了,即便有的话,可能对技术方面也不会太深入。
    3. 需要有一个人,他来对整个产品负责,这个人就是Product Owner,该角色最好由产品经理来担任。

    CSDN:敏捷开发过程中测试团队的职责和产出是什么?

    黄勇:在敏捷开发过程中,我认为测试团队的职责有以下几点:

    1. 根据产品需求,定义测试用例。
    2. 针对测试用例进行功能测试,并将测试的结果反馈给开发人员。
    3. 负责搭建系统运行所需的环境,包括软件安装、数据初始化等。

    CSDN:除了Scrum,还有XP、CM、FDD、ASD、DSDM等敏捷开发方法,如何去选择一个合适的敏捷开发工具或者方法呢?

    黄勇:敏捷开发方法有很多,不仅仅只有Scrum 一种,其实不妨相互借鉴,再结合自身的特点,定义一套适合自己的敏捷开发方法。例如XP 中所提倡的结对编程、持续集成、测试驱动等,这些都是很好的方法,值得借鉴。包括看板也是一个很不错的工具,可以结合Scrum 来工作。

    CSDN:从博客上,你也研究过「使用看板进行敏捷开发」,能不能分享你的研究成果?

    黄勇:敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

    我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

    • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。
    • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。
    • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

    可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!

    那么 Kanban 到底是什么呢?我们先来看看这张表格吧:


    下面我们来理解一下这个表格吧!

    • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)
    • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)
    • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

    在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

    实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

    需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

    也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

    对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

    好!继续我们的 Kanban,有意思的事情即将发生!


    产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

    开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

    开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了 然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


    现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


    有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


    部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


    此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


    完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


    所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


    部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


    整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


    看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


    几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。

    我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!

    展开全文
  • 上次Arthur老师给大家讲了敏捷开发模型之一的Scrum,这次给大家介绍的是敏捷开发的另一个模型——KanbanKanban,各位读者您没看错,英文也是这个。翻译过来就是特直接的——看板。 Kanban是一种高效管理软件开发...

    上次Arthur老师给大家讲了敏捷开发模型之一的Scrum,这次给大家介绍的是敏捷开发的另一个模型——Kanban。

    Kanban,各位读者您没看错,英文也是这个。翻译过来就是特直接的——看板。

    Kanban是一种高效管理软件开发过程的新技术,是丰田“准时制”(JIT)生产系统的基础。尽管生产软件是一种创造性的活动,因此不同于批量生产汽车,但管理生产线的基本机制仍然可以应用。

    软件开发过程可以被看作是一条管道,特征请求进入一端,改进的软件从另一端出现。在管道内部,会有某种过程,从非正式的临时过程到高度正式的分阶段过程。

    在本文中,我们先假设一个简单的分阶段过程:

    (1) 分析需求

    (2)开发代码

    (3)测试成果

    瓶颈问题

    我们想象一下:若干粗细不一的管子连接成一个管道,其中管道中的最细的那根管子限制了整个管道的流量,或者叫整个管道的吞吐量。我们姑且称之为“瓶颈”。

    以我们的开发流程为例:如果测试人员每周只能测试5个功能,而开发人员和分析人员每周有能力生成10个功能,那么整个管道的吞吐量将仅为每周5个特性,因为测试人员是一个瓶颈。

    如果分析人员和开发人员没有意识到测试人员是瓶颈,那么积压的工作将开始堆积在测试人员面前。

    如此一来,不可避免地,质量会受到影响。为了跟上步伐,处于瓶颈部分的人员开始偷工减料。生产过程中产生的问题会给用户带来问题,并浪费未来的管道容量。

    另一方面,如果我们知道瓶颈在哪里,我们可以重新部署资源来帮助缓解它。例如,分析人员可以帮助测试,开发人员可以在测试自动化方面工作。

    但是,我们如何知道在任何给定的流程中瓶颈在哪里?当它移动时会发生什么?

    使用Kanban动态地揭秘瓶颈

    Kanban非常简单,但同时也非常强大。在最简单的形式中,Kanban系统由墙上的一块大板组成,上面有卡片或便条,放在顶部有数字的列中。

    这些卡片表示工作项,因为它们在由列表示的开发过程中流动。每列顶部的数字是对每列中允许的卡数的限制。

    限制是看板和任何其他视觉故事板之间的关键区别。在流程的每一步限制在制品(WIP)的数量,可以防止生产过剩,并动态地揭示瓶颈,以便在瓶颈失控之前解决它们。

    举个栗子

    下面的Kanban板显示了这样一种情况:在测试人员释放出一个槽并拉入下一个工作项之前,开发人员和分析人员无法继续工作。此时,开发人员和分析人员应该考虑如何帮助减轻测试人员的负担。
    在这里插入图片描述

    请注意,我们已经将一些列分成两部分,以指示正在处理的项和已完成并准备好由下一个团队流程拉取的项。你可以用几种不同的方法布置黑板。这是一个相当简单的方法。拆分列顶部的限制包括“正在”列和“已完成”列。

    一旦测试人员完成了对一个特性的测试,他们就会移动卡并在“test”列中释放一个插槽。
    在这里插入图片描述

    现在“Test”列中的空槽可以由“development“done”列中的一张卡填充。这将释放“development”下的一个插槽,下一张卡可以从“analysis”列中提取,依此类推。
    在这里插入图片描述

    上面简单介绍了一下敏捷开发的Kanban模式。

    顺便说一句,在中国大陆,几乎每个开发团队都在搞“敏捷”,很多团队都声称自己做的是Scrum,实际上他们做的介于Scrum和Kanban之间。

    作  者: Testfan kitty

    出  处:微信公众号:自动化软件测试平台

    版权说明:欢迎转载,但必须注明出处,并在文章页面明显位置给出文章链接

    展开全文
  • 敏捷开发 模型讲解

    千次阅读 2017-03-01 16:56:54
    CSDN:在你的工作生涯中,前期是在创业公司,后来是大公司,有着一套自己的敏捷开发模式,能够谈谈在你现在使用的敏捷开发工具或方法? 黄勇:敏捷这个话题大家一直都在谈论,也有很多关于敏捷的工具或方法,我...
  • 敏捷开发之Scrum扫盲篇 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来...
  • 前面两篇文章,老司机给各位测试经理介绍了敏捷开发的两种模式:Scrum和Kanban。 那么两者有什么区别?且看下文一一拆解: 1、理念 Kanban和Scrum都围绕着敏捷开发的理念展开。在敏捷开发实践中,负责人都需要使用...
  • ThoughtWorks的敏捷开发

    千次阅读 2018-07-23 11:19:45
    ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代,为了让外界理解ThoughtWorks全球团队怎么做敏捷,我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发...
  • 微服务与敏捷开发(Scrum/Kanban)的核心思想之我见   关于“微服务”和“敏捷开发”的文章网络上有很多,所以这里不再重复叙述这些概念的解释和特点,而是就个人实际工作中对他们的核心思想的理解及运用分享给...
  • 只需要实践下一些敏捷开发模式就能如何如何,其实我觉得不论是敏捷开发还是传统的瀑布流开发都是有他们的市场的,取决于团队人员构成,取决你的产品的属性,所在市场的竞争环境。最终希望达到的目的都是一个:以最...
  • ​做软件开发的同鞋可能都或多或少的听说过敏捷开发,但是实际采用这种开发模式的项目场景可能就比较少了,今天针对敏捷开发能实际解决的问题做一个基本的介绍,让有兴趣的小伙伴能对敏捷开发的内涵有个基本的认识。...
  • 巧用Scrum与Kanban

    千次阅读 2018-09-18 13:14:53
    本文来自网易云社区文\屈鹏飞在互联网行业的项目管理实践中,敏捷和精益一直是大家所提倡的思想,其中Scrum和Kanban方法作为即敏捷又精益的典型代表,许多PM都在研究,笔者近期也在学习和实施Scrum和Kanban方法,...
  • 敏捷开发

    千次阅读 2016-07-14 18:45:16
    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把...
  • 原文转载自知乎Momenta专栏 走进敏捷软件开发——Scrum实施指南 Scrum是一种敏捷开发的模式,借助Scrum,团队可以实现产品的迅速迭代,十分适用于需求变化快的行业。...在讲Scrum这种敏捷开发模式之前...
  • 敏捷开发、持续集成/交付(CI/CD)、DevOps学习笔记 版权声明:原创内容,如需转载请联系作者。 https://blog.csdn.net/CrankZ/article/details/81545439 概述 敏捷开发和DevOps都是一种理念。他们的理念相似,...
  • 项目管理之敏捷开发之道

    千次阅读 2017-05-23 15:37:06
    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可...
  • 如图(一)所示,业务成功是最终目标,它需要有效开发模式的保障;开发模式的实施又离不开团队组织和技术实践的支撑;最后,通过持续改进、系统优化,获得持久的成功。这一层次关系中,外层是内层的目标,内层为外层...
  • 105.敏捷开发模型

    热门讨论 2020-03-23 23:25:54
    2.敏捷开发宣言3.站立会议的意义4.敏捷开发想解决什么问题?5.如果用敏捷的方式盖房子6.敏捷开发和瀑布模型的差异(1)敏捷开发是怎么做需求分析的?(2)敏捷开发是怎么做架构设计的?(3)敏捷开发怎么保证项目...
1 2 3 4 5 ... 20
收藏数 797
精华内容 318
关键字:

敏捷开发模式kanban