报名注册

门票种类

A 标准票:RMB3600元/张
B 团体票:RMB17500元/5张
C 团体票:RMB32000元/10张
待遇:全程案例分享、会议资料、2010年《驱动系列课程培训手册》含2日精致午餐。
目前从博客园购票可赠送今年夏天的主题T恤,详情请见:2010主题T恤

联系方式

imzzk@live.cn
联系博客园 1159478059
021-58950900
zhangkun@cnblogs.com

购买链接

>>去沪江网店购买

分享大师

  • 1
  • 2
  • 3
  • 4

陆宏杰
曾任微软亚洲工程院部门经理

具有十余年的需求分析、软件测试和项目管理经验,曾主管过多个大型复杂项目的需求分析和管理工作,尤其在测试对于项目的驱动力方面积累了大量的实际项目经验。

David.Zhang
曾任IBM(中国)有限公司项目管理部总监

在IT领域拥有19年经验,具有项目经理、业务发展经理、部门经理、项目总监、项目管理部总监等多种职位经验。 1994年加入IBM(中国)有限公司,服务于全球服务部(IGS)。

张 逸
曾任HP中国系统架构师

具有十余年的软件开发、设计和管理经验,曾先后担任高级软件工程师、项目经理、系统架构师、技术总监等职务。主要擅长.NET技术,包括 C#,ASP.NET,.NET Remoting,WCF,LINQ等。

张银奎
Intel亚太研发中心架构师

《软件调试》一书的作者,《程序员》杂志调试之剑栏目作者,高端调试网站(ADVDBG.ORG)的创始人。

亚太软件研发团队管理年会msup开放日(msup open day:mpd)专注于软件研发中心的快速成长,服务于软件开发团队的技能提升、软件工程的实际应用和软件品质的创新与超越。强调人员、技术、流程和管理的有机结合,注重个体的技能提升与职业发展,研发团队的管理与协作。分享世界级软件研发团队最佳管理实践,这正是mpd的精髓所在!

mpd北京站视频集锦

谁是打破旧制的伟大颠覆者与变革者?谁是带领研发团队走出困境的人? mpd开放日主要面向软件研发中心领导团队:首席技术官(CTO)、研发总监、项目经理、开发主管、架构师、测试经理、核心技术骨干等与软件研发团队密切相关的领导成员。 全场二十余个议题都是为研发团队精挑细选反复斟酌,分享、倾听知名软件研发团队带头人一线最佳研发管理实践。

7月10日 专场一:产品创新
(产品经理)
专场二:团队管理
(部门总监)
专场三:架构设计
(架构师)
专场四:项目管理
(开发经理)
专场五:测试管理
(测试经理)
09:00-11:50 IT产品创新地图与最佳方法体系总结
—— 周宏桥
项目中的团队管理:我是如何带团队的?
—— David.Zhang
对抗软件瑕疵的优良架构设计实践:Design For Debug!
—— 张银奎
敏捷之美: 冷眼看敏捷,构建真正的快速开发机制与攻略
—— 姜 伟
打造世界级高品质软件测试 团队:测试团队成长管理之路
—— 陆宏杰
13:30-17:30 拉动的力量:打造一站式在线生活的秘密
—— 王 坚
我在中国15年的发现: 研发系统的述职管理、绩效管理、指标设计!
—— 张伯明
架构设计之魂-贯穿软件架构设计的精髓
—— 汤涛滔
软件配置管理(SCM)驱动力:持续集成最佳实践(案例)
—— 董 越
大型软件组织的敏捷测试实践
—— 陈 扬
7月11日 专场一:产品创新
(产品经理)
专场二:团队管理
(部门总监)
专场三:架构设计
(架构师)
专场四:项目管理
(开发经理)
专场五:测试管理
(测试经理)
09:00-11:50 客户需求驱动的产品定义和规划 - 跨国公司产品创新之路及在中国的实践
——汪立耕
我在中国15年的探索:从技术走向管理、从优秀走向卓越
—— 张伯明
一线架构师驱动力:软件架构视图攻略与最佳设计策略
——刘 捷
微软产品开发组是如何管理需求评审、架构设计、开发交互这三个纬度的?
——陆宏杰
微软自动化测试经理:量身定做一套属于自己的软件自动化测试体系(案例)
——Paladim San
13:30-17:30 产品经理的五个最佳实践:用户、需求、项目、团队、战略
——苏 杰
高效管理IT研发项目与实践应用
——Daniel Liu
读大师作品(案例),透视软件设计原则与本质
——张 逸
产品规划设计阶段的项目管理
——Ray Zhang
借鉴微软全球软件测试规范和测试体系!
——袁孟轲

对抗软件瑕疵的优良架构设计实践:Design For Debug!

【分享概要】

软件瑕疵是软件工程的大敌,无数软件项目因为不断涌现的瑕疵而反复延迟,甚至干脆放弃。在已经发布给用户的软件产品中, 几乎无一不还存留着瑕疵,这些瑕疵轻者影响用户体验和产品销量,重者导致产品召回,甚至事故和灾难……。

如何对抗软件瑕疵呢?很多软件团队仍然使用着很原始的做法,好像在家里打蚊子一样,发现一只,消灭一只,缺乏科学和系统的方法。

本培训紧密围绕软件瑕疵这一主题,从软件瑕疵的成本曲线讲起,基于在集成电路领域广被认可的Design For Test(D4T)和Design For Debug(D4D)思想,系统介绍如何从产品的设计阶段就开始规划对抗软件瑕疵的基础设施,如何在产品编码和实现阶段利用这些设施及早发现瑕疵,如何在测试阶段更快的降低瑕疵数量,以及如何在产品发布后及时发现和修复残留的瑕疵。

本培训第一次将对抗软件瑕疵的主要理论和成功方法集成到一起,精选多个实际的软件项目和产品作为案例,结合讲师在软件领域的十几年工作经验,理论与实践紧密结合,让您在轻松的故事和有趣的演示中领会到成功的方法和经验。

课程大纲:

提纲 内容
可调试设计——设计阶段的最佳实践 想到的则不难、可调试架构、基本原则、日志、输出调试信息、沉重的 print、转储、基类、调试模型、 设计方案:代码的可追溯性、设计方案:数据的可追溯性、WMI、可配置性、可观察性、验证机制、追踪机制不可调试代码 这一部分将介绍如何在软件项目的架构设计阶段贯彻 D4T 和D4D 思想,规划对抗软件瑕疵的基础设施,包括如何实现数据和代码的可追溯性,可观察性,自检设施和错误记录、错误通知和错误报告设施。
自动诊断和远程报告——产品支持阶段的最佳实践 产品期瑕疵、WER、WER客户端、WER服务器端、WER服务、应用程序转储、遥感(Telemetry)、用户反馈、AutoBug、CEIP、Jon谈收益、实例分析:WDI 发布后软件可能运行在千差万别的用户环境中,测试阶段没有发现的瑕疵可能在用户那里暴漏出来。对于发生在产品期的软件瑕疵该如何寻找根源呢?本部分将以微软产品中广泛使用WER(Windows Error Report)机制为基础,详细介绍软件的自动诊断和远程报告技术。

敏捷之美:冷眼看敏捷,构建真正的快速开发机制与攻略!

【分享概要】

应该使用Lean,还是XP,或者Scrum?取决于团队的“湿度”以及“温度”。敏捷不是必杀技,它不能解决所有问题。实际上它是一种注重实效的“刀法”, 所有的招式都是为了“制服对方”,而不是挡住、击中或粘住对方的"劈砍"。同时,敏捷的招式也不是有气无力的,和所有的武功一样,它需要无数次的 实践与精炼来提高它的威力。在使用这些招式的时候,你必须了解每个招式的目的是什么?不能为了招式而招式,那毫无用处。小版本迭代的目标是为了 快速反馈,增长知识;测试驱动开发的目标是为了传播自信,提高设计的质量。而这些目标又构成了更深层的意义,那就是价值观。所以敏捷本身有它自 己的一套哲学体系:道-法-术-器。这四者必须有效的融合在一起。所有的敏捷方法都是一种博弈,它和我们日常的博弈没有什么不同。我们学习敏捷 的目地是为了:

获得原理,然后再打破它的束缚;因此人能自发独立于已有的武术,自然获得奇迹;当格斗来临,他能辨析其韵律,发出本能而正确的招数,自然而然...

课程大纲:

提纲 内容
破篇 不站位而得位,不防守而防守,意味着不能假设长刀要保持在一个固定的段位...把你的刀持在哪里要由你与对方的关系、地点决定,必须符合当时的情形;你是否持它,都要坚持这种想法,这样就会容易杀死对方...即便你可以挡住、击中或粘住对方的劈砍,或者拔开它或拦住它,所有的这些步骤都是砍到对方的机会。必须理解这一点... 1、软件经济学 2、软件心理学 3、冷眼看敏捷(部分敏捷工具箱) - 迭代、反馈交付价值 - 小步前进保证质量 - 沟通、交流尊重团队 - 总结、反思改善自我 - 再看敏捷方法论体系(法) - 敏捷宣言 - 敏捷原则

打造世界级高品质软件测试团队:测试团队成长管理之路

【分享概要】

经过了很多软件项目的风风雨雨,有成功的也有失败的。尽管每个项目都有自己独特的环境、背景、技术、市场和目标客户,参与的同事也各式各样,有中有外。但是有一些深层次的问题在每个项目都会遇到,例如人手不足、有些员工不太努力、客户需求不断变化等等。一开始我尝试加强工程师技能技巧的培训,希望通过员工能力的提高来解决这些问题。但是后来我发现这个思路是错误的!很多问题根本不是员工个人能力高低所能决定的,那么问题到底出在哪呢?让我们深入第一线体会一下,一个程序员不清楚要做的软件最终什么样,需求一天一变;不清楚自己的任务范围是什么,模块间的集成问题应该由谁负责;也不清楚质量标准是什么,什么样算是做完了;在这样的情况下这位员工即使编程技巧再强也像是拳头打在棉花上,无处发力。

让每一名员工都清楚自己的任务、进度、和结束标准,这说起来容易做起来难,这时我感到项目组急缺一种成体系的土壤,把各个部门当做一个部门来看待,部门间、流程中的运转不畅像一根喉咙中的梗刺,使整个项目组呼吸困难、内心焦躁。打破部门间的壁垒,从整体上建立一种质量体系的土壤,像一个项目组的操作系统,而开发、测试等部门则是操作系统上的应用,在同一时间,各部门分工越来越清晰、同时又依存配合越来越紧密,充分发挥员工潜能和资源配置,将各部门运转为一个整体的完美团队。

当然,所谓完美团队其实永远也没有真正的完美,只不过是在软件的项目组中不断追求让每一个人的每一分钟都在做正确而有意义的事情……

【目标收益】

分享如何将需求、开发、测试团队整合布阵,充分发挥团队效率潜能

课程大纲:

提纲 内容
质量意识 为什么选择测试职业 我们是否真的理解什么是质量 什么需要测试 测试工程师思维模式的3个维度 效果和效率 优秀测试工程师必备的8大素质
职业发展 什么是职业发展 专家路线的必要条件 管理路线的必要条件 开启测试领域全新境界

拉动的力量:打造一站式在线生活的秘密

【分享概要】

讲师在腾讯工作五年最大的心得是关于如何用平台对产品进行拉动,腾讯最初只有一个产品QQ,后来以QQ为平台,建立起来了强大的企鹅帝国,这其中到底蕴含了怎样的秘密......

课程大纲:

提纲 内容
Topic1用户进入产品的两大方式 拉动自然增长 为- 拉动,通过在平台上进行曝光,吸引用户进入 - 为什么产品经理要关注拉动?这不是营销经理的事情吗? - 自然增长,到底是如何增长的,真的“自然”吗?
Topic2拉动的三要素 导入用户数=(平台A活跃用户数x转化率x拉动时间)+(平台B活跃用户数x转化率x拉动时间)+... - 拉动的效果首先与所选平台的活跃用户数相关 - 转化率的两大影响因素是体验的封闭性和展示面积,例如网吧里卖饮料符合体验的封闭性,网吧里卖汽车就超出了体验的封闭性 - 持续时间越长,累计拉动效果越好
Topic3拉动的三种方式 广告植入融合 - 从用户对信息的接受心态来看,知道自己在被影响的是广告,不知不觉就被影响了是植入,用A直接变成了用A+B是融合 - 如何选取适当的拉动手段
Topic4口碑营销 硬指标与差异化个别人物法则 - 给自己的产品一个清晰独特的定位,是口碑营销的基础,如何做好产品的品牌包装? - 通过产品自身的硬指标与差异化,制造有效的口碑 - 通过内行和联系员,传播口碑,触达大众

我在中国15年的发现:研发系统的述职管理、绩效管理、指标设计!

【分享概要】

团队里每个开发人员的工作成果卖不出钱。只有捏在一起成为产品,才能卖出钱。然而捏在一起的过程常常十分痛苦,耗时费力,远超预期。如何减轻这样的痛苦?如何有效率的集成?如何让产品按时甚至提前发布上市?——这是一个软件配置管理策略方面的话题,正是本课程要讲述的。

课程大纲:

提纲 内容
Topic1 找到合适的人 1.研发人员胜任力素质模型的创建 a)研发人员的常规素质要求 b)18种素质的定义 c)研发胜任力素质模型的创建方法 * 调查问卷法 * B?E?I访谈法:某咨询项目的BEI创建过程演示 d)如何基于研发胜任力素质模型创建结构化面试试题库? * 演示:研发人员的结构化面试试题库 e)如何培养研发人员的胜任力素质? * 业绩评估 * 关键事件 * 案例的总结 * 知识库的建设 * 研发文化的建设 2.研发人员的晋升通道及技术任职资格 a)研发人员晋升通道图 * 管理系列 * 技术系列 * 技术管理系列,如QA b)任职资格和开发流程的关系 c)咨询项目演示:某公司的技术任职资格体系创建过程
Topic2 研发中高层领导:述职管理 1、研发高层领导述职管理的原则 2. 研发高层述职管理的模型 3. 研发高层述职管理的内容 a)述职报告的构成及关键内容 b)咨询项目演示:研发中高层的关键绩效指标(KPI)
Topic3 研发中层和团队:基于价值链的研发KPI 指标设计 1.业界公司KPI 指标制定过程中的误区 2.如何从端到端的流程的角度来设计研发的KPI 指标 3.研发体系KPI 指标制定的原则 4.介绍研发体系的KPI 指标库
Topic4 研发基层员工:PBC+PIP 1.研发基层员工的绩效目标来源 2.PBC(个人绩效承诺)的介绍 a)赢的承诺(WINNING) b)执行承诺(EXECUTION) c)团队承诺(TEAMWORK) 3.绩效承诺目标的跟踪与修订(PIP) 4.针对不同类型的员工如何进行绩效辅导 a)指挥倾向型 b)关系倾向型 c)思考倾向型 d)听命行事型 5.绩效评价及结果的应用

架构设计之魂-贯穿软件架构设计的精髓

【分享概要】

本讲座结合相关案例,分析架构师在设计过程中的目标、定位以及思想理念,是长期软件架构设计工作体验的总结,汇聚了国内诸多不同行业的代表性思维:

1. 架构设计的过程本身相当直接,所需要做的不外乎是搞清楚需求是什么,并且设计一个符合这样需求的系统。但是用户需求的变化似乎是永恒的,设计一个不变的系统去满足变化的需求就显得有些不可思议,这就涉及到架构设计的目标与定位如何才能适应用户与市场的发展需要?

2. 好的设计从何而来?架构设计的策略又有哪些?如何拥有持续的竞争优势?等等,这些是架构师通常需要花时间去总结和思考的问题。

课程大纲:

提纲 内容
Topic1 架构设计的目标与定位 - 软件架构与企业架构 - 架构设计的目标是什么? - 定位决定架构设计 - 好的架构设计是什么样的? - 如何在激烈的竞争下实现有优势的架构设计?
Topic2 职责与创新思维 - 软件开发过程中架构师的5大职责 - 软件架构设计的创新思维
Topic3 实现架构设计目标 - 实现架构设计的多维度技术视角 - 应用框架与架构设计实现 - 在不同层面上适应变更的设计

软件配置管理(SCM)驱动力:持续集成最佳实践

【分享概要】

团队里每个开发人员的工作成果卖不出钱。只有捏在一起成为产品,才能卖出钱。然而捏在一起的过程常常十分痛苦,耗时费力,远超预期。如何减轻这样的痛苦?如何有效率的集成?如何让产品按时甚至提前发布上市?——这是一个软件配置管理策略方面的话题,正是本课程要讲述的。

课程大纲:

提纲 内容
Topic1 集成概述 这一部分讲解系统集成的基本概念。什么是系统集成?谁负责集成?集成在软件开发流程中的位置?集成的目的和用途是什么?集成的优化目标是什么?
Topic2 集成成本分析 集成需要时间,集成需要人力,集成需要软硬件资源。逐项分析产生这些的成本的原因,以便进一步讨论如何降低成本。
Topic3 集成策略 讲解集成的关键策略,如持续集成,如保证提交质量。讲解这些策略背后的道理,以及如何根据企业具体情况灵活应用。
Topic4 集成实务 综合以上分析,详细讲解集成的步骤和流程,以及相关要点。

我在中国15年的探索:从技术走向管理、从优秀走向卓越

【分享概要】

团队里每个开发人员的工作成果卖不出钱。只有捏在一起成为产品,才能卖出钱。然而捏在一起的过程常常十分痛苦,耗时费力,远超预期。如何减轻这样的痛苦?如何有效率的集成?如何让产品按时甚至提前发布上市?——这是一个软件配置管理策略方面的话题,正是本课程要讲述的。

课程大纲:

提纲 内容
Topic1 知彼知己 & 技术管理者应具备的全局全局之路 - 研发人员有哪些特点 - 管理人员应梳理研发系统的职业发展通道 - 作为技术管理者,“既要低头拉车,又要抬头看- 路”,路在何方?-研发管理的业界最佳模式
Topic2 角色转换及必备的若干好习惯 1.技术管理者的角色与核心工作 2.确定游戏规则的方法: a)亚斯兰现象 b)破窗理论 c)蛇蛙原理 d)火炉法则 e)研发人员允许犯什么样的错误,不允许犯什么样的错误 3.创建团队文化 a)工程商人 b)避免盲目创新 4.习惯之一:成果导向 a)过程和结果的关系 b)追求过程的快乐还是成果的快乐 c)成果导向对研发管理者的要求 d)研讨:研发管理者在具体工作中怎么做才算是成果导向? e)研讨:如何保证FAQ真正有人看 f)研发的终极目标是什么? 5.习惯之二:综观全局 a)对研发各级管理者来说全局在哪里? b)综观全局的要求(理解自己在研发价值链中的位置和贡献) c)建立研发技术团队的创造性与规范性相结合的文化 d)研发工作的特殊性决定了创造性和规范性的冲突 6.习惯之三:聚焦重点 a)研发管理人员忙碌却无成效的原因剖析 b)研发管理人员的工作分类(四个象限)和时间管理 c)问题解答:谁都知道应当按四个象限安排工作顺序可为什么我们总安排不好? d)讨论:对研发管理者来说到底什么是重要的工作?领导交代的工作到底属于哪个象限? e)案例:李经理的工作如何聚焦重点 7.习惯之四:发挥优势 a)不同的研发人员有什么优势 b)是发挥优势还是克服弱点 c)发挥优势要求我们做到什么 d)采用什么方法才能发挥不同研发人员的优势 8.习惯之五:集思广益 a)怎样才能使研发团队绩效最大化 b)因为差异(四个层次)所以要集思广益 c)研发冲突的原因 d)集思广益经常使用的方法论(脑力激荡法、德尔菲) 9.技术管理也是管理与艺术的结合 a)管理者需要具备“火眼金睛”:本计划有泡沫吗? b)管理工作中的“抓大放小”

一线架构师驱动力:软件架构视图攻略与最佳设计策略

【分享概要】

本讲座结合相关案例分析,解决架构师工作之中经常遇到的若干实际问题。

1、软件架构师的交付件(软件架构视图和架构文档).为什么需要架构视图,需要哪些视图,如何描述架构视图以及项目的最佳实践。

2、软件架构的驱动因素,架构师架构设计前的考虑因素.架构的质量属性,如何描述,如何制定相应的架构策略。

课程大纲:

提纲 内容
Topic1 架构师如何输出自己的架构成果,是相关人员能够理解和沟通 - 如何编写软件架构的文档 - 架构文档应该包含的信息 - 软件架构视图的意义, 软件架构师的多维思考 - 常见的系统架构视图 - 典型案例分析:结合多个项目案例,分析真实项目软件架构视图
Topic2 架构师在设计架构师,应该考虑哪些因素,抓住系统的架构核心驱动因素 - 软件质量需求对架构的影响(质量属性场景定义和对应架构策略) - 软件功能需求对架构的影响(分析功能需求变化点和进化点) - 软件约束条件与架构的影响(业务,运行环境,开发团队,实现技术等约束) - 如何使功能性需求,非功能性需求和平台细节在架构中能保持分离,从而改善可维护性和可扩展性 - 典型案例分析:结合项目,分析驱动因素

微软产品开发组是如何管理需求评审、架构设计、开发交互这三个纬度的?

【分享概要】

从实际问题出发,注重解决软件项目中有关需求分析的现实问题,剖析需求挖掘和获取的实用技巧,形式上并不拘泥于各种理论图形表达法,分享能真正解决问题的经验,课程定位不仅仅是如何成为一名优秀的需求分析员,更重要的是分享如何通过需求管理提高项目的整体效率和产品定位,课程内容包括需求获取和需求分析的方法和技巧、需求应该细致到什么程度、对需求部门的管理,同时涉及需求和架构的配合、需求和测试的配合、以及需求对整体项目的驱动力。

【目标收益】

  • - 如何在客户无法说清的情况下获取和分析需求
  • - 用户需求不断增加和变化,如何处理变更对项目的影响
  • - 团队对设计目标的理解不一致
  • - 需求分析过程同软件开发过程严重脱节
  • - 无法有效的将从客户获取的信息转换成软件设计文档
  • - 开发人员和需求分析人员互相不认可,无法形成有效的协作
  • - 需求不明确,开发和测试很难开展

课程大纲:

提纲 内容
Topic1 需求和架构的配合 需求的分解需要结合整体设计架构并发进行,这一部分内容着重讨论需求与架构之间的相互影响和协调策略
Topic2 需求文档的规范及需求评审的流程和技巧 如何确保需求内容达到公司可接受的程度;如何保证需求可以满足项目组的综合要求;如何处理需求阶段和开发阶段的衔接及相应标准
Topic3 需求和开发的交互 从需求的角度理解开发效率;从开发的角度理解需求分析;需求应该细致到什么程度对开发来说才具备可操作性

微软自动化测试经理:量身定做一套属于自己的软件自动化测试体系

课程大纲:

提纲 内容
Topic1 软件测试自动化的一键搞定 - 走进软件测试自动化 - 流程分析: It is Team Work! - 软件测试‘全’自动: 一键搞定 - 软件测试自动化的误区 揭开软件测试自动化的神秘感, 了解自动化测试流程的一般性和特殊性, 展现能够一键搞定的’全’自动化测试是什么样子的,分析软件测试自动化中容易犯的错误
Topic2 功能测试的自动化 - 市面上流行的自动化测试工具分析 - 自动化测试的架构设计 - 自动化测试DIY – UI Automation - UI Automation中的核心知识 - 怎样用UI Automation一步一步写自动化 通过比较分析市面上流行的自动化测试工具, 了解其实用性和局限性. 自动化测试的架构设计是核心,本章节将重点讲解。另外讲解Microsoft UI Automation. 目标是让学员摆脱仅仅依靠测试工具来实现简单的自动化测试,从而能够自己设计和实现自动化测试, 掌握其核心, 从某种意义上说, 仅仅会使用record and replay tool是对自动化测试较为肤浅的理解。
Topic3 Model based 自动化测试设计 - 什么是model based 测试 - Model Based能做什么测试 - Spec Explorer工具 - Spec#语言 - Model based自动化测试的具体步骤 本节是精讲章节之一. 目前 国外Model based测试设计应用相当广泛。如果掌握可以很快的提高自动化设计和实现的过程, 优化测试。然而国内还是空白. 本章节讲解model based 测试的具体知识和操作步骤, 而不是泛泛的谈理论.另外讲解微软的一个软件自动化测试的工具SpecExsplore。通过三个实际的例子让学员学会model based自动化测试的具体步骤。请注意,Spec Explorer不是图形界面测试的record and play工具
Topic3 软件测试中各种测试的自动化 - 软件中的安全问题和稳定性问题讲解 - 自动化测试中的Fuzz和Stress测试 - 全球化测试和本地化测试的自动化设计 - 性能测试的自动化设计 大型企业级软件的测试远不至功能测试. 本章节全面的介绍软件测试中其它各种测试的自动化实现。通过挖出内存中call stack来讲解为什么fuzz 和stress 测试能提高软件的安全性的稳定性。详细的介绍设计和实现Fuzz和Stress测试的详细步骤。并且结合本人实际的工作经验,介绍了fuzz测试中的两个关键点。另外详细讨论全球化测试,本地化测试,性能测试的自动化设计。

产品经理的五个最佳实践:用户、需求、项目、团队、战略

课程大纲:

提纲 内容
Topic1 为什么要做产品经理 生活中的好产品与坏产品,产品经理可以改变世界
Topic2 产品经理要做什么 我过去3年的经历,正好总结成一幅画
Topic3 产品经理怎么做 用户、需求、项目、团队、战略,每个话题提一两点
Topic4 人人都是产品经理 产品经理的思路与方法可以解决很多实际的生活问题,至少,你已经是自己的产品经理

高效管理IT研发项目与实践应用

[分享概要]

本课程结合IT项目的特点,以美国项目管理协会(PMI)的项目管理知识体系(PMBOK)为知识背景,讨论如何高效管理IT研发项目的范围、时间、人员、成本和沟通。课程将基于project2007作为支撑。

[课程对象]

IT项目经理、项目群经理和项目管理办公室人员。

[课程目标]

  • 有效地跟踪和控制进度并预测项目的进展
  • 编制出满足项目中干系人需求的定制的报告和视图
  • 监测和管理跨项目的资源负荷
  • 管理复杂项目和项目群

课程大纲:

提纲
Topic1 确定项目目标确定项目生命周期模型初始化项目信息建立项目组
Topic2 编制范围计划 - 获取项目需求 - 确定项目范围 - 编制工作分解结构(WBS) 编制时间计划 - 估算任务工期 - 建立任务依赖关系 - 使用期限、限制和任务日历 - 浏览时间计划 编制资源、成本计划 - 创建和修改资源分配 - 输入项目估算 - 浏览资源计划 - 浏览成本计划
Topic3 建立基线 如何进行有效的任务更新 更新项目 - 根据计划更新 - 重排未完成任务的开始时间 更新任务 - 更新工期 - 更新工时 - 更新成本 识别偏差并修订预测 纠正项目偏差 - 缩短项目的工期/提前项目完成日期 - 调整资源的工作量 - 降低项目的成本 变更控制
Topic4 挣值分析(EVM) 利用视图、表、报表分析项目 选择、编辑和生成基本报告 定制域、表、报表、视图等 配置打印和页面设置选项 导出报告数据 创建和修改可视报表
Topic5 多项目管理介绍 创建主项目 建立项目间的依赖关系 计算一条或多条关键路径 保存和打开多个项目 在多项目间共享资源并优化资源分配 通过数据分析、定制视图、挣值分析和多维数据集报告和分析项目

读大师作品(案例),透视软件设计原则与本质

【分享概要】

面对纷繁复杂的软件系统,如何利用设计原则和模式提炼出解决方案?是从软件设计中寻找普遍存在的规律,还是透过设计看本质,利用本质的思想与原则来指导我们的设计?学习设计模式,如何才能做到既不流于内容空泛的理论堆砌,又不至于陷入细节的泥沼,一叶障目,以偏概全,失去把握设计脉络的大局观。本次课程通过阅读大师作品,解析JUnit和NHibernate等著名开源框架,以及.NET框架和JDK API,通过理论指导实践,通过实践抽象理论,对软件设计进行一次提炼与升华,是思想、原则与模式的大碰撞。七种武器迭出,助你劈荆斩棘,越过迷雾透晓设计本质。

课程大纲:

提纲
武器一:复用(Reusability) 代码的坏味道——解决方案蔓延 DRY原则 复用的方式——继承与组合 对象的粒度——迪米特法则 合理的封装 保持对象的高内聚 模式参考 - 简单工厂模式 - 原型模式 - 代理模式 - 门面模式 - 模板方法模式 阅读大师作品: JUnit中对异常的重用 JUnit中的Assert断言 - ASP.NET MVC中的Copy Constructor - 泛型工厂类
武器二: 扩展(Extensibility) 如何实现扩展 - 利用继承实现扩展 - 利用组合实现扩展 - 利用继承与组合实现扩展 - 利用抽象实现扩展 模式参考 - 装饰器模式 - 访问者模式 - 策略模式 - 命令模式 - 状态模式 - 职责链模式 - 观察者模式 阅读大师作品 - JDK中线程的运用 - .NET中对文件流的处理
武器三:分离(Separation) 职责分离 分离与抽象、依赖的解耦 分离体现的设计原则 对象的职责 分离的目标 模式参考 阅读大师作品
武器四:变化(Change) 隔离变化 模式参考 阅读大师作品
武器五:简约(Simplicity) 简约的本质:简单+优雅 重构和精益求精 如何考量简约 模式参考 阅读大师作品
武器六:一致(Coherence) 惯例优于配置 Liskov替换原则 模式参考 阅读大师作品

10年软件历程:项目计划及项目计划跟踪的最佳实践

【分享概要】

我们经常在重复软件项目管理的“三边六拍”运动(三边:边计划、边实施、边修改,六拍:拍脑袋、拍肩膀、拍胸口、拍桌子、拍屁股、拍大腿),为了解决项目管理的问题,“敏捷运动”应运而起,然则“敏捷”往往成为“手工作坊”的漂亮外衣!

项目计划及计划跟踪是项目管理的重中之重,本课程你将面临一个个来自于现实项目的挑战,“敏捷”不是说出来的,而是一个一个具体的实践,老师将与你分享一个个实用的项目计划及跟踪的最佳实践。

【课程特点】

极限编程、SCRUM、MSF等敏捷理论给我们描述了敏捷开发的美好境界,然则在中国有点水土不服,我们需要符合中国软件项目特点、能直接解决具体问题的最佳实践。讲师在多年的项目管理中,锤炼了符合实际情况的各种最佳实践。课程将最佳实践融入到一个个具体的案例,让学员通过不断的思考而掌握这些最佳实践。

【适合听众】

项目经理、开发经理、产品经理、有志于往项目管理方向发展的人士。

课程大纲:

主题 提纲 内容
Topic1 实用估算 预算与估算的区别 估算的两种情况 由底而上的估算 实战:由底而上的估算
Topic2 项目管理目标 项目管理钻石五角:功能、成本、进度、质量、发展 针对钻石五角设定“跳起来够得着”的目标。 案例分享:设定项目管理目标
Topic3 进度计划 “远粗近细,持续更新”的进度计划策略 三大驱动:估算、风险、目标驱动 版本规划、优质任务、缓冲时间 实战:制定优质任务
Topic4 计划执行与跟踪 项目跟踪策略:前细后粗、持续辅导、注重首次 案例分享:每日例会 案例分享:项目组成员自管理
Topic5 总结 从总体上降低工作量。 让项目组成员充分参与、持续提升技能。

借鉴微软全球软件测试规范和测试体系!

【分享概要】

结合讲师本人在微软美国总部与微软北京亚洲工程院的十多年的实际开发、测试与团队管理的经验,为您讲述有关技术管理方向的方方面面。本课程主要面向于在研发团队中已经具有3-5年工作经验的初、中级研发、测试管理人员。主要介绍的内容将包括研发团队的开发、测试流程的管理;研发、测试团队中的代码版本管理、构建方式与缺陷管理;一个技术团队的招聘、组建;技术团队成长过程管理;技术团队的氛围管理;技术团队的绩效管理;技术团队的技术职称体系的建立与管理职称体系的建立与评估等。

本课程将以职场中的典型案例的分享与介绍为主,适当结合在软件工程学和管理学中的相关理论,为大家介绍在当前业界一流公司中的各种先进的管理方法和管理理念。同时,讲师将在课堂上鼓励与支持与大家的互动和分享,以使大家可以相互学习,共同提高,并且易于将所学到的知识应用于今后的工作中去。

课程大纲:

提纲 内容
Topic1 研发团队的开发、测试流程管理 - 微软公司超大规模软件标准研发流程介绍 - 新型敏捷开发流程的应用与介绍
Topic2 大型软件开发过程中的代码与版本管理  
Topic3 大型软件开发过程中的构建方式与编译管理  
Topic4 大型软件开发过程中的缺陷管理  
Topic5 一个优秀技术团队的形成 - 招聘与组建 - 技术团队的成长过程管理 - 技术团队的氛围管理 - 技术团队的绩效管理;
Topic6 技术团队管理的其他方面 - 技术职称体系的建立 - 管理职称体系的建立 - 绩效评估与成长潜力的评估 -有关经理与团队的绩效与评估等

上海国际会议中心简介:上海国际会议中心素以举办大型国际会议、商务论坛的专业性与综合性蜚声海内外。多种规模和类型的会议室配以先进完善的会议设施, 可满足您的任何需求。上海厅面积达到4400平方米。此外,酒店另设有28个大小不等,风格迥异的多功能会议厅。届时,作为mpd开放日的参与者将可以亲眼目睹和 亲身体验这座作为中国目前最大无柱形多功能厅、位于世博园内地理位置优越、周边配套完善的会议中心。使您在轻松享受服务同时,坐享超越成功巅峰体验。

交通路线

1、地铁线路:

  • 地铁1号线:到人民广场换乘地铁2号线到陆家嘴站下车;
  • 如果是从浦东国际机场出发,可坐机场三线到龙阳路地铁站下车,换乘地铁二号线到陆家嘴站下;
  • 如果是从虹桥机场出发,可坐941路(虹桥机场-上海火车站)到娄山关路站下车,到陆家嘴站下。

2、公交线路:

国际会议中心,位于上海市浦东新区滨江大道2727号(东方明珠旁)。途经的公交线路主要有: 583、621、623、776、778、870、872路、申高线、旅游江园线(滨江大道终点站)、82、85、581B、795路、陆家嘴环线(陆家嘴地铁站终点站)、81、797、983、旅游3号线、锦江观光巴士到东方明珠后步行5分钟即到。

由麦斯博(MSUP)主办的mpd大会于2010年3月在北京国家会议中心成功举办。此次大会邀请了曾任微软亚洲工 程院部门经理的陆宏杰、IBM中国特约讲师姜伟、HP 系统架构师汤涛滔等二十多位著名技术专家登台演讲。