精华内容
下载资源
问答
  • 敏捷开发 所有角色 有人再次问我有关他们敏捷过渡的自我评估。 这让我开始思考过渡到敏捷的问题。 我不认为敏捷在任何情况下都适合每个人。 有人声称敏捷已经“跨越了鸿沟”。 当然,许多人都知道敏捷。 许多人都...

    敏捷开发 所有角色

    有人再次问我有关他们敏捷过渡的自我评估。 这让我开始思考过渡到敏捷的问题。 我不认为敏捷在任何情况下都适合每个人。

    有人声称敏捷已经“跨越了鸿沟”。 当然,许多人都知道敏捷。 许多人都知道跨职能团队的工作量是递增的,提供了征求反馈的功能。 那是在团队层面。

    您已经看到了我对一般敏捷团队的总体印象,并且以防万一您不记得了,这里又是。

    Johanna's General Agile Picture

    约翰娜的通用敏捷图片


    因此,当我说“敏捷不适合所有人”时,我是什么意思?

    问题是敏捷不仅限于团队。 团队安装敏捷后,团队就会遇到系统性管理问题。 管理层必须乐于改变。 程序管理必须愿意改变。 人力资源必须乐于改变。 金融必须愿意改变。 好大 我们正在谈论改变组织的文化。

    您不必在第一天就改变文化。 但是您最终必须进行更改。 从团队开始是一个好的开始。 如果团队无法进行持续集成和足够小的故事以进行为期两周的迭代,那么敏捷就不适合他们。 当我说两周的迭代时,我的意思是在两周后发布。

    任何人都可以过渡到敏捷。 这需要工作和决心。 我看到了以下阻碍人们过渡到敏捷的问题:

    1. 敏捷要求您开始管理项目组合 哦,也许不是一开始,但最终还是会的。 您不能在项目上执行多任务并成功。 您是否愿意说是的,您现在将提交一些项目,而不是现在提交一些项目? 而且,您将继续练习,以确保您的团队不会过载? 而且,您不会像棋子那样移动人吗?
    2. 如果您想加入更多的团队,这并不像将一个团队的工作成倍增加那么简单。 那会让你肿。 我已经有几篇有关程序管理的帖子,您可以期待更多的帖子。
    3. 敏捷需要开放的文化。 您愿意在各个层面上给予和接受反馈吗?
    4. 敏捷邀请团队认可和奖励。 您是否愿意至少讨论如何进行团队评估,认可和奖励? 您是否愿意讨论如何建立不会自动将人员转移到传统管理领域的职业阶梯? 您是否愿意重新考虑什么是管理以及您需要多少? 您是否愿意考虑如何将现在称为“管理”的内容转移到普通人的工作中?
    5. 敏捷需要透明。 您愿意对谁做出哪些决定保持透明吗? 您是否愿意对管理决策的界限保持透明?
    6. 敏捷不容易采用每年一次的预算。 它邀请增加的资金。 但是,财务部门不了解增量资金。 在创建软件时,利用软件资本化仍然很困难。 金融更喜欢里程碑。 我们如何帮助金融公司实现大写? 对于软件即服务,这是一个更简单的问题-您决定何时发布足够大写的字母。 对于非SaaS产品,要困难得多。 你愿意尝试吗? 财务愿意尝试吗?

    您现在可以看到敏捷不仅是生命周期,而且是组织的巨大文化转变? 对于项目团队来说,这是许多生命周期中的一个,但是对于组织而言,生命周期远不止于此。

    如果您无法保持向敏捷的过渡,则不应感到羞耻或担心。 你不是一个人。 您可以做的就是阅读“ 管理它”! 您的《现代实用项目管理指南》 ,并重新阅读了生命周期一章和附录。 生命周期有很多选择。 而且,借助您对时间框的了解,将功能划分为小故事,对故事进行排名,创建跨职能团队,将测试集成到迭代中,您将拥有出色的RUP或分阶段交付生命周期。

    我并不是说敏捷是针对精英的。 离得很远。 我说的是敏捷是针对想要并且能够管理其所需的文化变革的人们的。 而且,如果您尝试执行我们建议的许多技术和项目管理实践,那么您会变得更好。

    但是敏捷是目标吗? 还是为客户交付产品的项目想要您的目标?

    敏捷是一种手段。 这不是唯一的工具。 选择适合您文化的车辆。

    我全力以赴。 对我来说,那才是最重要的。 如果您需要敏捷评估,那么您就可以选择错误的树。 您需要查看今年是否比去年更有效。

    参考:《 产品开发管理》博客上的JCG合作伙伴 Johanna Rothman指出, 敏捷并非适合所有人

    翻译自: https://www.javacodegeeks.com/2012/12/agile-is-not-for-everyone-2.html

    敏捷开发 所有角色

    展开全文
  • 敏捷开发团队中PO和SM角色介绍

    千次阅读 2017-05-14 09:48:51
    敏捷开发团队中PO和SM角色介绍 2013年05月20日 没有评论 19,832 views 通过前面几篇关于敏捷开发总体的相关介绍,相信大家对敏捷开发模式已经有了一个比较清晰的了解,后续会介绍一些比较细分的方面,...

    敏捷开发团队中PO和SM角色介绍

    通过前面几篇关于敏捷开发总体的相关介绍,相信大家对敏捷开发模式已经有了一个比较清晰的了解,后续会介绍一些比较细分的方面,结合我在敏捷开发实施过程当中的一些体会,来阐述自身对敏捷开发的认识。

    敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的(指一个办公室内坐在一起的),建议由产品经理担任,本身产品经理已经是所有业务的接口人,熟悉业务是其本职工作;如果产品经理和开发、测试团队是两地办公的,如设立的研发中心、外包服务等形式的,建议在开发团队内指定一个人来担任PO,这样产品经理在第一次PRD全体review之后,只需跟这个PO讲解清楚产品逻辑,后续开发和测试当中遇到的问题,都可以咨询PO来得到解决,PO不确定的可以联系产品经理确认,这样可以减少一部分的沟通成本。

    敏捷开发中的SM即Scrum Master,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

    Product Owner(PO)

    Product Owner角色定义

    确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROI(profitability of product)负责。 是维护产品需求清单( product backlog )的人,代表利益相关者的利益。

    Product Owner工作职责

    负责最大化产品以及开发团队工作的价值。主要职责如下:

    1、确定产品的功能;

    2、决定发布的日期和发布内容;

    3、为产品的ROI负责;

    4、根据市场价值确定功能优先级;

    5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

    6、接受或拒绝开发团队的工作成果;

    7、参与Scrum Planning Meetings(Sprint计划会议),Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)

    Product Owner

    Product Owner在团队中的作用

    在junior团队中:主要的需求来源,个人确定需求价值和优先级

    在intermediate团队中:多角度的收集需求,和团队成员共同确定需求的价值和优先级

    在Senior团队中:和团队成员共同提出和收集需求,共同对产品负责

    这里的团队分级主要是指团队的敏捷成熟度,即产品团队实施敏捷开发模式后,对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。

    一句话总结PO这个角色就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

    Scrum Master(SM)

    Scrum Master角色定义

    是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

    Scrum Master并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者,他是Scrum团队中的服务型领导。

    Scrum Master工作职责

    确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

    1、保证团队资源合理利用;

    2、保证各个角色及职责良好协作;

    3、解决团队开发中的障碍;

    4、作为团队和团队外部的接口,协调解决沟通中的问题;

    5、保证开发过程按计划进行,组织Scrum Planning Meetings(Sprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)。

    Scrum Master

    Scrum Master在团队中的作用

    在junior团队中:主导和控制

    在intermediate团队中:引导和教导

    在Senior团队中:辅导和协助

    一句话总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

    案例分享

    某Team在Plan Meeting会议中,邀请了PO参加,但PO因会议时间冲突未能参加,在讨论Sprint  Backlog的时候,因需求有变动,团队未完全按照product  backlog上的优先级去拿,选好Sprint  Backlog 后,Scrum master详细讲解了每一条Sprint  Backlog应该如何拆分及理由,最后给出了每个task的评估工时。

    问题一:PO未参加计划会

    应与PO提前协商时间,若PO没有时间需调整时间,PO一定要参加;

    问题二:未按已排定的优先级做

    如果不按照product  backlog上的优先级去拿需要和PO一起决定;

    问题三:SM一个人完成需求拆分和工时评估

    任务的拆分及工时的评估需要和团队共同确定,不是Scrum master一个人说了算。

    在敏捷开发团队内部,PO和SM角色是非常重要的,基本决定了团队是否可以很好的执行敏捷开发这种模式,因此这两个角色一定都要十分熟悉敏捷开发的整个运转流程,带领和引导团队一步一步的往敏捷的方向迈进。很多时候PO和SM的不专业,很容易使团队偏离敏捷的模式,因此决定一个团队能否完全进入敏捷开发模式时,这两个角色很关键。


    展开全文
  • 敏捷开发 所有角色 在“敏捷项目经理的职责”第1部分中 ,我描述了促进敏捷项目经理的职责。 在“敏捷项目经理不做什么”的第2部分中,我描述了一些更传统的项目经理可能会认为他们的工作仍然存在的角色,即使他们...

    敏捷开发 所有角色

    “敏捷项目经理的职责”第1部分中 ,我描述了促进敏捷项目经理的职责。 “敏捷项目经理不做什么”的第2部分中,我描述了一些更传统的项目经理可能会认为他们的工作仍然存在的角色,即使他们应该/正在使用敏捷。

    有时,人们对应该促进和不应该采取的措施感到困惑。 那是因为他们的角色已经改变。 敏捷项目经理协助团队决定如何做的工作。 产品负责人(敏捷中的新角色)决定做什么以及团队要交付的工作的等级。

    这些变化导致期望和团队工作方式出现问题。

    我已经通过以下方式看到了期望问题:

    • PO认为团队不需要将故事分解成团队可以每天(或更经常)完成的事情。
    • PO认为团队无法帮助编写故事。
    • PO认为团队不需要解决团队可能存在的遗留问题。 相反,PO具有功能性

    当采购订单不了解其角色时,敏捷项目经理可以帮助采购订单了解该怎么做以及如何对待团队。 请参阅我的PO系列。 摘要是产品所有者和学习,第5部分

    我也看到了团队问题,例如专家讲故事(甚至估算“他们的”故事并讲“他们的”故事)。

    在尚不了解流程效率但仍使用资源效率思想的团队中,PO可能甚至鼓励各个专家总结自己的“故事”。 (这些事情通常是任务,而不是故事。)PO希望以最有效和最有效的方式完成功能。 PO可能会鼓励团队成员讲述自己的故事。 或者,PO可能会要求这样做。

    事情就是这样:每个人都想以最有效的方式制作功能并完成工作。 如果敏捷项目经理了解流程效率背后的想法,那么敏捷项目经理可能会说或做以下任何事情:

    • 什么也不说,开始累积流程图以查看团队的在制品。
    • 问:“在我们的团队规范中,我们说我们不想独自讲故事。 我们正在修改规范吗?” 然后,等待看看人们的回答。
    • 说:“当人们加强专业知识而不是分享专业知识时,我会面临风险。 是时候考虑其他选择了吗?”

    如果您是敏捷项目经理,您可能会说或做完全不同的事情。 我已经在不同的团队中尝试了所有这些方法。 我有不同的结果。 如果人们对流量效率持开放态度,我们可以取得进步。 有时候,人们感到如此压力,他们无法想象另一种工作方式。 这意味着我不得不在不同的层次上工作,以了解人们为什么会感到这种压力。

    如果有人希望团队在特定日期之前交付某些功能,那该怎么办? 这就是采购订单的职责范围。 所有的。 如果PO强度不足以承受压力,会发生什么情况。 在那里,敏捷项目经理可以通过以下方式帮助PO:

    敏捷项目经理执行与命令和控制项目经理不同的工作。 敏捷项目经理关注团队的系统性障碍和工作流程。 这并不容易!

    翻译自: https://www.javacodegeeks.com/2016/10/agile-project-manager-product-owner-roles-intersect-part-3.html

    敏捷开发 所有角色

    展开全文
  • 敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的...

    通过前面几篇关于敏捷开发总体的相关介绍,相信大家对敏捷开发模式已经有了一个比较清晰的了解,后续会介绍一些比较细分的方面,结合我在敏捷开发实施过程当中的一些体会,来阐述自身对敏捷开发的认识。

    敏捷开发中的PO即Product Owner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的(指一个办公室内坐在一起的),建议由产品经理担任,本身产品经理已经是所有业务的接口人,熟悉业务是其本职工作;如果产品经理和开发、测试团队是两地办公的,如设立的研发中心、外包服务等形式的,建议在开发团队内指定一个人来担任PO,这样产品经理在第一次PRD全体review之后,只需跟这个PO讲解清楚产品逻辑,后续开发和测试当中遇到的问题,都可以咨询PO来得到解决,PO不确定的可以联系产品经理确认,这样可以减少一部分的沟通成本。

    敏捷开发中的SM即Scrum Master,字面意思是敏捷专家或者敏捷大师,即熟悉敏捷开发模式及敏捷实施流程的人员,一般可由敏捷团队当中的开发负责人担任,部分能力很强且懂技术的产品经理也可担任这个角色,因涉及到工作量评估和分派等工作,最好都是由技术能力较强的人员担任。

    Product Owner(PO)

    Product Owner角色定义

    确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品ROI(profitability of product)负责。 是维护产品需求清单( product backlog )的人,代表利益相关者的利益。

    Product Owner工作职责

    负责最大化产品以及开发团队工作的价值。主要职责如下:

    1、确定产品的功能;

    2、决定发布的日期和发布内容;

    3、为产品的ROI负责;

    4、根据市场价值确定功能优先级;

    5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

    6、接受或拒绝开发团队的工作成果;

    7、参与Scrum Planning Meetings(Sprint计划会议),Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)

    Product Owner在团队中的作用

    在junior团队中:主要的需求来源,个人确定需求价值和优先级

    在intermediate团队中:多角度的收集需求,和团队成员共同确定需求的价值和优先级

    在Senior团队中:和团队成员共同提出和收集需求,共同对产品负责

    这里的团队分级主要是指团队的敏捷成熟度,即产品团队实施敏捷开发模式后,对敏捷开发模式的适应程度、接受程度和学习程度。后面会专门介绍团队的评估标准。

    一句话总结PO这个角色就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

    Scrum Master(SM)

    Scrum Master角色定义

    是团队的导师和组织者,与Product Owner紧密合作,及时为团队成员提供帮助。促使team按照scrum方式运行,为Scrum过程负责的人。

    Scrum Master并非团队的领导(因为团队是自我组织的),而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者,他是Scrum团队中的服务型领导。

    Scrum Master工作职责

    确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下:

    1、保证团队资源合理利用;

    2、保证各个角色及职责良好协作;

    3、解决团队开发中的障碍;

    4、作为团队和团队外部的接口,协调解决沟通中的问题;

    5、保证开发过程按计划进行,组织Scrum Planning Meetings(Sprint计划会议), Daily Stand-up Meeting(每日站会), Sprint Review Meeting(Sprint评审会)和 Sprint Retrospective Meeting(Sprint回顾会)。

    Scrum Master在团队中的作用

    在junior团队中:主导和控制

    在intermediate团队中:引导和教导

    在Senior团队中:辅导和协助

    一句话总结SM这个角色就是:教整个团队怎么做,如何估时,跟进每天进度,风险控制,定期总结,计划排定。

    案例分享

    某Team在Plan Meeting会议中,邀请了PO参加,但PO因会议时间冲突未能参加,在讨论Sprint? Backlog的时候,因需求有变动,团队未完全按照product? backlog上的优先级去拿,选好Sprint? Backlog 后,Scrum master详细讲解了每一条Sprint? Backlog应该如何拆分及理由,最后给出了每个task的评估工时。

    问题一:PO未参加计划会

    应与PO提前协商时间,若PO没有时间需调整时间,PO一定要参加;

    问题二:未按已排定的优先级做

    如果不按照product? backlog上的优先级去拿需要和PO一起决定;

    问题三:SM一个人完成需求拆分和工时评估

    任务的拆分及工时的评估需要和团队共同确定,不是Scrum master一个人说了算。

    在敏捷开发团队内部,PO和SM角色是非常重要的,基本决定了团队是否可以很好的执行敏捷开发这种模式,因此这两个角色一定都要十分熟悉敏捷开发的整个运转流程,带领和引导团队一步一步的往敏捷的方向迈进。很多时候PO和SM的不专业,很容易使团队偏离敏捷的模式,因此决定一个团队能否完全进入敏捷开发模式时,这两个角色很关键。

    展开全文
  • 敏捷开发角色和职责阐述

    千次阅读 2019-05-18 18:58:21
    敏捷开发中的PO即Product Owner,产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。如果敏捷团队是在一起办公的,建议由产品...
  • 敏捷开发规范

    2018-09-21 16:49:00
    1 概述 1.1 编写目的 该文档的主要目的是为了在团队中实施敏捷开发,加速产品交付周期,为敏捷开发提供相应的...2 敏捷开发团队中的角色及名词解释 2.1 product owner product owner也叫产品经理,负责整理u...
  • 敏捷开发实践

    2014-03-28 13:12:02
    本文主要是讲在开发团队中实践敏捷开发: 1 角色 在瀑布模型中,所有的流程是预先定义的,角色更是根据流程而划分,如下图 在敏捷中,定义的角色有 利益相关者(stakeholder) 产品所有者(pro
  • 敏捷开发

    2018-12-01 16:46:02
    角色 和 职责 产品 负责人 产品 负责人 是 Scrum 团队 和 客户 之间 唯一 的 联系。 产品 负责人 要对 最终 产品 负责, 他们 负有 以下 相应 的 责任。...所有开发团队成员都应该清楚的知道项目的长...
  • Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。在每一次冲刺(一个15到30天周期,长度由开发团队决定),开发团队创建可用的...
  • Scrum的角色定义。 Scrum会议简介。 实际项目中ScrumMaster的定位。 用户故事的拆分与管理:Jira管理用户故事。 非技术型ScrumMaster如何应用度量指标。 大数据Scrum团队案例分享。 当前内容版权归码字科技所有并...
  • 结伴 敏捷开发 我们都去过那里。 您正在开始一项新工作,甚至不知道洗手间在哪里,更不用说完成该工作所需的所有工具和过程了。 由于开放式组织的非结构化环境和开放式文化,因此入职甚至更加棘手。 定义角色可能由...
  • Scrum中有3种主要的角色:产品所有者、Scrum主管和团队成员 产品所有者和团队成员一起工作,负责维护产品积压工作表(production backlog),并对表中的项指定优先级 软件在多轮时间限定的迭代中完成开发,这些迭代...
  • 敏捷开发SCRUM

    2011-07-18 20:21:00
    Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。 在每一次冲刺(一个15到30 天周期 ,长度由开发团队决定),开发团队创建可用的...
  • 敏捷开发_WorkBalance

    2013-07-16 21:29:36
    传统的开发团队通常按角色就行分工, 开发人员只管开发, 测试人员只管测试, 在自己的职责之外的事, 要么是看不见, 要么是觉得不是我的活,我不用去管,做好做坏和我没有关系。 而敏捷软件开发恰恰相反, 更加...
  • 敏捷开发Scrum框架具有以下角色:产品所有者(Product Owner)、Scrum Master、Scrum Team。当然还有项目干系人(Stakeholders)。Scrum框架的所有这些角色都有其重要性,在本文中,我们将详细讨论产品所有者...
  • Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者...
  • 敏捷开发-srcum

    2016-07-25 10:48:00
    SCRUM框架包括3个角色、3个工件、5个活动、5个价值...1.Product Backlog 指根据初始需求分解出的任务列表,包括功能性和非功能性的所有功能, 2.Sprint Backlog (冲刺 储备) 3.Burn-down Chart 燃尽图 5个会议 1.S...
  • scrum 敏捷开发流程 scrum 标准流程图解析 三种角色 产品所有团队scrum master backlog PO(产品所有者)听取客户\经理出 出功能需求表(backlog) backlog按照功能优先级排列 backlog就是一个列表 backlog没有详细...
  • Scrum是一种迭代式增量软件开发过程,通常...Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。、 Scrum中有3种角色,分别是产品负责
  • 结合工具来实现敏捷开发 - 5

    千次阅读 2011-08-11 21:27:29
    按照Scrum的基本理论,Scrum是一种迭代...Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。这个网上都能找到。 我们先从中提炼出一些
  • Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者...
  • (13.2.1)Scrum敏捷开发框架

    千次阅读 2017-05-16 11:04:07
    Scrum角色 Scrum基本工件 Scrum活动或会议 ...它是敏捷宣言的价值观和原则背后的重要思想源泉,⽽这些价值观和原则也是所有敏捷⽅法的基础 Scrum是一个用于打造产品的框架,一个团队流程。当利益干系人需要
  • 为何要做scrum? 1. 对项目开发速度要求加快;关键功能需要能够段时间内上线;小步快跑; 2. 项目过程中客观上需求变化大,变化急促; ...1. 所有scrum成员需要统一培训,on the same...3. 明确团队成员在开发过程中价值

空空如也

空空如也

1 2 3 4 5 ... 7
收藏数 131
精华内容 52
关键字:

敏捷开发团队所有角色