2007-05-22 12:22:00 springleft 阅读数 1180
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

敏捷开发的实践中,工具是敏捷的第一环节,因为他直接决定了我们工作和交流的具体内容,工具一方面提高了工作的效率,一方面也改善了团队交流的质量.将团队开发的工作与交流限制在可以控制的范围内,就是我们选择和使用敏捷开发工具集的原则.并且,使用工具来改善团队开发的工作和交流的重要性已经超越敏捷开发的概念,它是一项在任何开发模式下都具适用性的开发方法论。由于我们对敏捷的传统的理解和工具能快速带来软件生产的改进的原因,所以,还是把开发过程中的工具集称之为敏捷开发工具集.


1.平台: Eclipse
2.开发工具: Borland Jbuilder 2007,BEA workshop studio
3.配置管理:Subversion,Subclipse
4.编译管理:Maven2,M2eclipse,Ant
5.代码生成:Xdoclet
6.持续测试:Junit,TestNG,DbUnit,Selenium,cargo,
7.持续集成:Bamboo
8.代码质量:Metrics,Jupiter,Checkstyle,Eclemma(Cobertura/Coverlipse),CPD,Jdepend
9.知识管理:Confluence Wiki
10.IM工具/事件通知:QQ/QQMail
11.计划管理: Project,JIRA
12.任务/需求/缺陷管理工具:,Mylar,JIRA

todolist:
一.工具集的协同与整合
二.开发过程指导

2019-08-24 22:36:52 seagal890 阅读数 65
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

[敏捷开发实践] 使用RACI Matrix划分敏捷团队的R&R

参加过PMP认证培训,持有PMP认证的Project Mananger都清晰的理解RACI Matrix 的重要性。

事实上,无论项目规模大与小,团队规模大与小,如果你想在一个项目上有效的提升沟通效率和执行效率,那么RACI Matrix就是一个有力的工具。使用RACI Matrix组织团队中的人员,明确各自的角色和职责,让每个人都知道谁负责什么,当发生问题是应该找谁沟通更有效等等……

让我们来看看RACI 的英文解释:

  • R = Responsible:谁负责。及负责执行任务的角色,具体负责项目执行,解决问题。
  • A = Accountable:谁批准。即对任务负全部责任的角色,只有经过该角色同意和审批之后,项目/工作任务才可以实施。
  • C = Consulted:咨询谁。即拥有完成项目所需的信息和能力的人员。
  • I = Informed:通知谁。即拥有特权、应及时被通知结果的人员。但是不必向他咨询或者征求意见。

补充说明:

R 是实际完成工作任务者,任务可由多人分工,完成的程度由A决定。

A 是最终责任承担着,也是工作任务负责者,具有确定的工作分配和决定权力,每个任务活动只能有一个A。

C 是最后决定或行动之前必须咨询的人。可能是上级管理者,也可以是客户的利益代表者。沟通是双向的,必须为A能够提供决策依据;为R提供行动依据和指南。

I 是信息通知者,一个决策或行动完成之后,必须被告知的人。沟通是单向模式。

使用RACI的优点

  • 明确每个团队成员的工作职责和工作分工
  • 定义团队成员之间的沟通模型
  • 诊断项目资源的配置情况

SCRUM团队中的RACI Matrix

F - Facilitate activities (促进活动)

总而言之,担任F角色的人员,为Scrum项目提供便利和组织活动,如下图所示。在Scrum环境中使用RACI,激发了PM专业人员之间有趣的讨论。一些人认为,这种模式将向一个人提供对一项工作的认可,即一项工作做得好,或者一项工作执行得不好,这会影响团队凝聚力。这种组织方式将影响Scrum的基础——自我组织。包括反论点,必须考虑到外包人力和人力(文化差异等)的适用范围。为了发挥RACI的潜力,建议在自我组织团队中的角色和责任以及灵活性之间找到平衡点。

RACI Matrix

Functional

Manager

Scrum

Master

Product

owner

Scrum

Team

Project

Manager

Ensure consistency of Scrum practices across team I C C I R/A
Provide vision and goal for the product I I R/A I I
Provide resources with the right skills and mind-set R/A I I C/I C
Prioritize and manage the product backlog I F R/A C F
Remove impediments R R R/A R R
Manage the release train I I C C R/A
Make sure Scrum practices are used and improved within the team R R/A C R F
Create, apply and continuously improve the difinition of done C F R R/A F
Report on time to management I F R/A I F
Define acceptance criteria I F R/A C F
Write acceptance tests I F C R/A F
Ensure quality of the product R R R/A R R
Manage Risks C C R/A C R

Approve User Stories

(User Stories meet the acceptance criteria)

I F R/A C F
Decide on release date and goal I I R/A I I

如何让RACI有效的适用

如上所述,这种责任分配矩阵是有效的。

要知道如何应用这个模型,你应该分析,分析,分析!平衡是你获得成功的关键。如果每个角色中的人员太多或不够,则会减慢项目任务的完成,甚至会阻止完成。

要有效使用RACI,请确保:

  • 每项任务一个负责人。如果你有不止一个人,那就好像有多个人在开车一样。它不起作用!如果没有司机,就很难让那辆车向前行驶——项目上没有任何决定或行动。
  • 适当数量的R。分配给同一个任务的人太多了,你有一个很好的方法来浪费时间。你也可能得到重复的工作。如果你有一个快速简单的任务,R也可以是A。
  • 不要有太多的C:这会减慢任务的完成。如果你在完成任务前需要和几个人商量,那你还有另一个浪费时间的人,那就是你自己。或者,会导致关于如何完成任务的冲突。
  • 随时通知项目中的其它成员和干系人。也许你不需要咨询别人,你只需要更新提供给他们的信息。确保你有人担任这个角色,否则你可能会遇到缺乏沟通有关的问题。

Scrum Master如何使用RACI Matrix

通过以下6个步骤从使用RACI矩阵中获益:

  • 项目任务列表
  • 确定项目利益相关者
  • 了解每项任务的R和A及其利益相关者(Stakeholders)
  • 至少有一个利益相关者负责每项任务(A的角色)
  • 只有一个利益相关者(Stakeholder)承担A的角色
  • 最后一步包括与所有利益相关者的讨论。这是为了确保利益相关者理解他们的角色。

企业实际项目中存在的问题及误解

1、Scrum Master 和 Project Manager能是一个人吗?

2、Functional Manager 和 Project Manager能够是一个人吗?

3、Scrum Master 到底是听从Functional Manager的指挥还是 Project Manager的指挥?

4、如果 Product Owner 不能及时给予项目有力的支持或者及时提供/反馈项目信息,怎么办?

5、谁是Scrum Master的领导(Leader)?

6、Scrum Team中需要另外设置一个 Development Leader/Manager吗?

7、除了Product Owner之外,如果某个Stakeholder干预项目工作,包括New Features、Sprint迭代周期,开发进度怎么办?

8、Product Owner和Scrum Master、Functional Manager、Project Manager之间的冲突怎么解决?

以上在项目实践中存在一系列真实发生的问题和误解。怎么破?

后续慢慢讨论解决。

 

2020-01-06 23:12:59 u011210017 阅读数 5
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

1. 何为敏捷

敏捷是基于一种不确定性较高,未来环境难以预测的背景下产生的一种管理理念,这种理念并不意味着应该丢弃传统的管理方法中的一些方法而是应该以快速传递价值给客户为目标进行管理,只要某个方法能加速我的价值传递就应该使用。

敏捷宣言

  • 个体和互动高于流程和工具
  • 工作的软件高于详细的文档
  • 客户合作高于合同谈判
  • 响应变化高于遵循计划

以上价值观并不是右边不重要,而是认为左边更重要。

十二原则

客户为主:我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。

拥抱变化:欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。

短迭代交付:要不断交付可用的软件,周期从几周到几个月不等,且越短越好

业务参与:项目过程中,业务人员与开发人员必须在一起工作。

以为人本:要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。

面对面沟通:无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。

成功导向:可用的软件是衡量进度的主要指标。

保持节奏:敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

追求卓越:对技术的精益求精以及对设计的不断完善将提升敏捷性。

简单务实:要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。

团队自组织:最佳的架构、需求和设计出自于自组织的团队。

持续改进:团队要定期反省如何能够做到更有效,并相应地调整团队的行为

2. 敏捷生命周期

预测型——类似传统的瀑布型

迭代型与增量型

敏捷型

四种生命周期的区别

3. 敏捷团队

自组织

大量个体基于简单规则的互相作用,无需中央调控,能够涌现出整体上的新秩序

组建高绩效团队

致力于共同的目标,并为了实现绩效 目标自主承担共同的责任

主要特点

具备合适技能和积极性的人员

承诺和有效授权

建立信任

胜于其他团队并超过预期

保持可持续的速度去交付高质量软件

一致性和可预见的速度

具备技术水平和商业知识

主要特征

参与式领导力

有效的决策

开放和清晰的沟通

价值多样性

相互信任

管理冲突

清除目标

明确定义角色和职责

协调关系

积极的氛围

敏捷教练——仆人式(服务式)领导

特点

   以身作则,乐于成为仆人,以服务来领导

   倾听并支持团队做出决策

   理解他人,具备同理心

   鼓励并支持每个个体的个人发展

   劝说,而非使用权利

   主动寻求帮助他人,并信守承诺

   在跟随者中建立信任

   提前思考未来,超越每日实现

职责

   教育相关方法,使其了解为什么要敏捷以及如何敏捷

   通过指导、鼓励和帮助团队提供支持

   通过技术项目管理活动

   庆祝团队成功

   为团队与外部团队合作提供支持,并起到桥梁作用

   创造互相欣赏的积极氛围,建立加强合作的良好意愿

敏捷团队激励

马斯洛需求理论

   金字塔五层:生理需求、安全需求、爱与归属 的需求、自尊需求、自我实现需求。只有低层次满足了才会产生高一层级的需要

赫兹伯格双因素理论

   激励因素:来自工作条件本身,能带来满意、成就,例如:重视、成就、个人成长

   保健因素:是必须的但是不能给予激励,缺少它会导致不满意,例如:地位、工作安全、薪水等

   敏捷项目团队需要保健因素去建立最低水平的团队绩效。同样,激励因素决定团队是否能实现高绩效

大卫动机理论

   追求成就

主要激励因素 应类型人的特征
成就

设定和完成挑战性目标的强烈愿望

愿意承担可能的风险去完成目标

愿意收到来自进展和成就的反馈

社交

喜欢有集体归属感

想要被喜欢

喜欢协作竞争

不喜欢高风险或不确定性

权力

 喜欢权力和影响他人

 享受竞争和胜利

 享受地位和重视

4. 敏捷实践

 精益软件开发(LSD)

  解决影响生产过程中的问题

   过度:对于雇员和过程施加不必要的额外压力

   违规:不切实际的需求导致过程中的不均匀

   浪费:非增值活动或过程

  精益 7 原则

 极限编程(XP)

一种基于频繁交付周期的软件开发方法,一种开发哲学,基于以下五大价值观

验收测试驱动开发(ATDD)

   Discuss:讨论

   Distill:提取

   Develop:开发

   Demo:示范

测试驱动开发(ADD)

   编写测试代码

   核对和确认测试

   编写产品代码,j接着采用测试

   重构产品代码

Scrum

Scrum流行的原因

   Scrum提供简单和可证明的结果

   它包含其他敏捷工程技术

   它强调小型团队和团队授权

   欢迎需求的变更

   它允许单一来源的优先项目工作开展

   Scrum会议包括日常状态会议

   提供团队在冲刺阶段一个潜在的可交付增量承诺

  三大角色

产品负责人——告诉团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理

Scrum Master——引导团队建立团队规则,维护团队和指导团队外部成员遵守团队规则,移除团队障碍

开发团队——执行冲刺,包括:每日检视和调整、梳理产品列表、冲刺规划、检视和调整产品与过程

 三大工件

产品待办列表:一份涵盖产品中已知所需每项内容的有序列表,它是产品需求变动的唯一来源

冲刺待办列表:一组为当前Sprint选出的产品待办列表项,同时加上交付产品增量和实现Sprint目标的计划

产品增量:一个Sprint完成的所有产品待办列表的总和,以及之前所有Sprint所产生的增量的价值总和

五大会议

产品待办事项梳理——为即将到来的冲刺做准备,并对事项进行分解和估算

冲刺计划会议——如何完成交付所需的工作

每日站立会议——检查冲刺目标的进度,并检视完成冲刺待办列表的工作进度趋势

冲刺评审会议——产品负责人说明待办项列表的完成和未完成;开发团队讨论冲刺期间做得好的、碰到的问题及解决方法

冲刺回顾会议——Scrum团队检视自身并创建下一个Sprint改进计划的机会

Scrum实施流程

 

5. 敏捷工具

用户画像

  PERSONA七要素

   P代表基本性(Primary):指该用户角色是否基于对真实用户的情景访谈;

   E代表同理性(Empathy):指用户角色中包含姓名、照片和产品相关的描述,该用户角色是否引同理心;

   R代表真实性(Realistic):指对那些每天与顾客打交道的人来说,用户角色是否看起来像真实人物;

   S代表独特性(Singular):每个用户是否是独特的,彼此很少有相似性;

   O代表目标性(Objectives):该用户角色是否包含与产品相关的高层次目标,是否包含关键词来描述该目标;

   N代表数量性(Number):用户角色的数量是否足够少,以便设计团队能记住每个用户角色的姓名,以及其中的一个主要用户角色;

   A代表应用性(Applicable):设计团队是否能使用用户角色作为一种实用工具进行设计决策

  可以用来克服项目成员在产品开发过程中的若干难题

   需求分析阶段:确定产品功能以及用户行为的优先级,辅助场景设计,让产品更为聚焦。

   产品设计阶段:协助与项目成员以及利益相关者进行沟通交流,就设计意见达成共识和承诺。提高设计效率。

   用户调研阶段:许多其他的用户研究环节对于用户的招募以及研究内容确定都需要依据persona。

   产品策略阶段:明确市场推广方向、预估市场规模,更准确地为产品做决策以及定位市场

用户故事

三要素

   角色:谁要使用这个功能

   活动:需要完成什么样的功能

   业价值:为什么需要这个功能,能带来什么价值

3C原则

   卡片(Card):用户故事一般写在晓得记事本卡片上

   交谈(Convertsation):用户故事背后的细节来源于和客户或产品负责人的交流沟通

   确认(Confirmation):通过验收测试用户的故事被正确完成

六个特性-INVEST

   独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。

   可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。

   有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方)。

   可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。

   短小(Small)— 一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。

   可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的

确定用户故事优先级

   相对优先级=价值/工作量 估算每个故事的价值和工作量,计算相对优先级。

   莫斯科(MoSCoW)规则

     必须有(Must have):基本功能

    应该有(Should have):很重要但是短期内有替代方案的功能,如果没有时间约束,此类功能是强制性的

    可以有(Could have):没有时间就可以在发布中不予考虑的功能

    这次不会有(Won't have this time)

   卡诺Kano模型:有时候基础型需求部分实现就可以了,尽可能多的完成期望型需求,确定少量兴奋型需求。

估算——对交付计划产品所需要的成本、进度、投入或者技能进行的预测

  敏捷估算基础

   估算让团队可以了解项目规格,计算ROI和IRR,形成项目执行许可的基础。

   敏捷团队基于产品负责人的投入来估算需求,Scrum Master进行保守估算。

   敏捷估算在整个项目期间进行。在项目逐步完善中更多信息出现,团队定期评估新需求。

   团队使用计划扑克或者亲和估算等技术来确定需求估算。

  准确性和精确性

   敏捷估算致力于准确性而非精确性,因为实现精确性让估算过程拉长并且昂贵

   故事点:描述一个用户故事及其相关努力总体规模的测量单元

    特点

    分配故事点需要考虑的

    故事点估算的步骤

  估算规模敏捷评估旨在合理预测估算,不追求精确

   两种非线性规模常用于估算

   宽带德尔菲

    宽带德尔菲的步骤

    计划扑克

 

2016-03-13 12:41:46 u010173255 阅读数 474
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

 敏捷开发的宣言:

个体和互动优于流程和工具

      强调的个体成员在执行敏捷方法中的重要性,充分体现了人是实施工作的主体,整个项目的运作都是以人为主导,而不是过程。过程是次要的辅助,根据项目的情况可以抛弃或是保留参考。在此,个体成员的能力在敏捷方法实施成功与否至关重要。个体成员对敏捷的能力是关键因素,实施敏捷的能力基础。在管理的能力实践和技术实践中,都需要对个体成员敏捷能力的修炼和提升,这是必不可少的部分。传统的项目管理中,沟通是项目经理基本的素质,也是解决问题最有效的手段。在敏捷团队中,个体的沟通互动能力也是不可或缺,敏捷的实施过程,能够通过面对面沟通解决的,就不要通过管理工具进行传递,每次的沟通都是高效准确的。

      敏捷不是“银弹”,每个成员都要充分沟通,表达各自得观点想法,从多方面去取得足够敏捷方法的相关信息,可参考相关的敏捷论坛社区的实践和案例分享,客观的看待认识敏捷利弊。


工作的软件优于详尽的文档

     在传统的项目管理中,文档承载着项目过程中每个环节阶段之间的信息传递。如果环节中没有提供详尽的文档,工作则不能有效的往下展开。我认为编写详尽的文档是一个把控项目的好办法,但这样会消耗过多的文档编写的时间开销,同时软件系统承载的是复杂的业务,需要长时间梳理澄清才能把细节理清。项目的有效时间花费在文档制作,势必对项目的开发、测试工作的时间造成影响,影响了软件 的质量。敏捷中不是完全的否认了文档,项目是可以根据自身的情况来定哪些过程文档需要输出,那些过程文档可以简化,那些过程文档可以抛弃。

     敏捷也是可以输出文档,文档是否需要,在与在项目周期内,交付出高质量的软件为依据。如,开发人员能力较弱,则输出对应的程序设计文档。


客户合作优于合同谈判

     合同是项目的起点,包括了一些法律条文、交付产品里包含的功能和交付时间。而在项目的实施过程中,客户方变更合同的相关条约或功能需求也是常见的。通常会要走比较繁琐的合同变更流程,一下项目进度的同时也增大了投入成本。通过合同进行交付产品,安功能交付,在完成前真正的使用用户没有在过程中体验软件,造成产品部满意、不实用的情况也是很正常的。

    敏捷中提倡与客户合作的关系,保持良好的沟通,把客户切实的参与进项目实施的有效环节中来,如对开发过程中的使用体验、客户的功能需求及时的反馈等,与客户的合作是在商定的项目周期内可以交互为前提。


响应变化优于遵循计划

     及时响应变化是敏捷的核心。软件是个复杂的的东西,业务需求、技术和人员都有可能影响项目计划,这些因素都存在着太多的不确定性,因此通常要坚持既定计划是不太可能的。通常对于项目组为了保证”遵循计划“,体现管理能力与计划能力,始终对外宣称项目组运行状况良好,保证当前人员在预计时间肯定能保质保量的完成开发,用其它不直观的项目因素作为代价,如开发人员的代码质量、测试的充分性等。

    敏捷当项目发生困难时影响到了项目计划进度,则及时的调整计划,适应项目现状,以积极的方式响应变化。


2016-08-19 16:32:38 xylylx 阅读数 22
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10433 人正在学习 去看看 CSDN讲师

敏捷软件开发

敏捷软件开发是一种面临迅速变化的需求快速开发软件的能力。

敏捷宣言:

1.个体和交互胜过过程和工具 团队沟通是很重要的

2.可以工作的软件胜过面面俱到的文档  软件无二义性

3.客户合作胜过合同谈判 

4.响应变化胜过遵循计划 只为近期任务做详细计划,远期任务做粗略计划

 

通过迭代,每个人都知道将要做什么以及何时去做。其他人可以看到项目的进展。

测试驱动开发

重构

 

敏捷开发

阅读数 2744

没有更多推荐了,返回首页