敏捷开发引进pdd概念_zcc pdd - CSDN
  • 敏捷开发一千零一夜

    2013-07-26 10:03:07
    敏捷开发一千零一夜(国内首部以真实敏捷实施案例为主线的案例集) 王立杰 主编 ISBN 978-7-121-20818-8 2013年8月出版 定价:49.00元 244页 16开 编辑推荐 覆盖组织转型、产品管理、团队建设、工程实践...

    敏捷开发一千零一夜(国内首部以真实敏捷实施案例为主线的案例集)

    王立杰 主编

    ISBN 978-7-121-20818-8

    2013年8月出版

    定价:49.00元

    244页

    16开


    编辑推荐

    覆盖组织转型、产品管理、团队建设、工程实践,解析精彩过程,分享经验教训,揭示敏捷背后的奥秘。

    汇集IBM、淘宝、京东、暴风影音等IT名企的敏捷专家经验分享。

    内容提要

    本书以多位作者的亲身经历,再现真实的敏捷实施过程,描述各个企业在实施敏捷的过程中,遇到的种种问题、解决的思路及最终得到的经验与教训。这本案例集从不同的视角,为读者展示从大型互联网企业到初创公司、从大型国企到独资外企、从典型的甲方到第三方咨询公司的敏捷历程。这里面既有大的组织的敏捷转型,也有一个小团队或个人的敏捷历程,还涵盖某个敏捷实践或工具的应用描述。

    本书的特色在于由真实实践提炼,对正在实施敏捷的读者具有很高的参考价值。

    目录

    第一篇  组  织  篇

    第1章  暴风敏捷项目管理实践          2

    一、暴风的项目危机     2

    二、组织级的敏捷初体验     3

    三、再次组织级探索     12

    四、持续优化的力量     18

    五、组织改进中人的因素     27

    第2章  淘宝的敏捷实践与过程改进          35

    一、背景介绍         35

    二、不同背景下的解决方案         36

    三、ScrumMaster心得 50

    四、敏捷与过程改进     51

    五、工具的支持     54

    第3章  从CMMI5到敏捷   57

    一、案例背景         57

    二、敏捷导入过程         60

    三、敏捷优化改进过程         70

    四、整体回顾         81

    第4章  从装甲兵团到特种部队          83

    一、引子         83

    二、实施过程         88

    三、反思         95

    第二篇  产  品  篇

    第5章  火星人一千零一夜          98

    一、第一个月:一个产品的诞生         98

    二、第二个月:框架优先,还是故事群优先     101

    三、第三个月:故事树         103

    四、第四个月:用户故事的颗粒度(上)         105

    五、第五个月:用户故事的颗粒度(下)         108

    六、第六个月:用户故事的分类         110

    七、第七个月:分类语法     114

    八、后记         115

    第6章  从敏捷到精益          117

    一、背景         117

    三、破窗理论         121

    四、敏捷宣言错了吗     125

    五、南辕北辙         127

    六、MVP才是王道         129

    七、跨越鸿沟         135

    八、小结         136

    第三篇  团  队  篇

    第7章  敏捷英雄传之火烧赤壁          140

    一、人物介绍         140

    二、故事梗概         141

    三、引子         142

    四、CEO孙权的故事:计划永远赶不上变化     144

    五、CTO周瑜的故事:究竟是变好,还是变得更烂          148

    六、产品经理太史慈的故事:一个大版本经理的困惑     152

    七、编码狂人凌统的故事:主刀,就是能上得天堂,下得地狱的主儿         157

    八、测试经理陆逊的故事:敏捷测试,就是明知不可为而为之     161

    九、产品集成主管甘宁的故事:持续集成的烦恼     162

    十、臭皮匠的话     167

    第8章  打造学习型自适应团队          168

    一、背景介绍         168

    二、团队实践过程         169

    三、回顾与反思     181

    第9章  从传统软件开发到敏捷的初体验          183

    一、背景         183

    二、迈出第一步     187

    三、对第一次迭代的改进     192

    四、关键的第三次迭代         196

    五、第四次迭代:低耦合软件设计     197

    六、总结         199

    第10章  敏捷在传统软件与互联网中的应用   200

    一、背景介绍         200

    二、敏捷实施过程         201

    三、回顾与反思     207

    第四篇  实  践  篇

    第11章  敏捷无它,唯持续改进       210

    一、背景介绍         210

    二、我与敏捷的第一次亲密接触         210

    三、敏捷原来是这样的         211

    四、第一个挑战     213

    五、团队的好奇心         213

    六、更多挑战         214

    七、团队的惯性     215

    八、镜子         215

    九、从一开始就要高标准     216

    十、TDD的争议     216

    十一、“道”与“术”  217

    十二、程序员文化         217

    十三、程序员与建筑工人     218

    十四、TDD不是目的,“拉”与“推”       218

    十五、Coding Dojo 219

    十六、让实践落地         219

    十七、程序员的产出     220

    十八、权威     220

    十九、认同权的建立:无私,勇于说不知道     221

    二十、成就感:点燃程序员的热情     221

    二十一、PDD:痛苦驱动开发      222

    二十二、排除障碍,创建舒适的技术环境         223

    二十三、投资回报率     223

    二十四、让领域模型裸奔     224

    二十五、架构         224

    二十六、你做什么就是什么(You are what you do)         225

    二十七、Scrum是不行的,如果只有Scrum       225

    二十八、做正确的事情 vs 正确地做事情 226

    二十九、问题和解决方案,5-whys     226

    三十、“为什么”  227

    三十一、估算(动词)很有帮助,但估算(名词)往往没有         228

    三十二、守破离     228

    三十三、测试优先         228

    三十四、QA vs QC 229

    三十五、分享:Wiki、博客、书籍、技术讨论、编程练习      229

    三十六、没有银弹,只有持续改进     230

    三十七、敏捷宣言         230

    第12章  网龙持续集成实践       231

    一、案例背景         231

    二、案例分享         232

    精彩节摘

    1.展示板和信息系统的巧妙结合

    敏捷例会的展示板每个团队都会实施得不一样。对于进度跟踪,可以采用观察燃尽图的趋势,也可以融合信息系统的做法。

    只要不苛刻地挑剔,很多工具都支持Scrum敏捷项目管理,从最简单的白板加Excel,到ScrumWiki、Xplanner、GNATS都能支持Scrum的实施。暴风的团队开始就尝试了Redmine这个缺陷管理工具来配合展示板实施敏捷项目管理。没有好不好用的系统,只要运用合理,抱着极简的思维去使用工具,就能最低成本地发挥工具的作用,至于使用信息系统遇到的各种缺陷或者不能满足管理的功能,还是应该报以宽容的态度。但理想和现实往往经常事与愿违,将就用了一段时间后团队终于不能忍受系统功能的不足,于是开发自己的信息系统的呼声愈演愈烈,最终还是决定开发自己的系统。

    还是本着极简的思维方式,系统只围绕包括Sprint任务导入、任务完成更新(工时填报)、燃尽图自动生成、问题的生命周期管理这样几个核心功能进行开发。这样也使得任务板和信息系统的信息完全一致,障碍(问题)也得到了有效的跟踪和管理。

    2.配置管理的敏捷实践活动

    对于暴风影音的官网版本来说,每个月会有多个官网版本发布,一种是提供给用户新特性验证的β版本,根据用户体验后真实的反馈信息,进行后续产品的优化和完善,另外一种是将已经完成验证的功能和新特性合并到稳定的官网版本中。基本每两周就要交付一个版本,每个项目都感觉时间紧、任务重。配置管理在敏捷实践中起到怎样的作用呢?

    暴风转码的敏捷团队在版本V2.1刚刚完成用户故事的开发工作,也就是说,产品已经能运行,系统测试工作还未开展。按照估计测试和修改Bug的周期为一周计算,此一周的时间研发人员会很不饱和,按照公司对人员使用率的要求,通常会启动V2.2版本的开发工作。这样会提高研发人员的利用率,但也会带来两个甚至多个版本同时开发的问题,如果没有好的配置管理,代码会混乱不堪,很多人同时并行两个版本的代码开发工作,一方面改V2.1版本的Bug,另一方面开发V2.2版本的新功能。我们通过配置管理工具的代码分支、代码合并来解决代码管理问题。为V2.1开出代码分支,这样两个版本的代码相互隔离,不会彼此干扰。V2.1版本上的Bug修复工作,对于V2.2的开发同样也适用。这样实现了版本的交替开发,提升了开发人员的使用率。通过代码的分支与合并也能处理好“新特性开发”与“产品稳定”的关系。两种版本经常存在交叠。用分支支持交叠,即防止了前者干扰后者,也防止了后者阻滞前者,这样维持了开发效率和产品质量的平衡关系。

    在敏捷开发过程中,变更是被鼓励的。而变更一定会体现在代码中,因此在SVN里,加一些控制以保证开发人员做且只做该做的事。方法是让变更集不由开发人员创建,而是由专门的配置管理员创建,然后指定给相应的开发人员完成。配置管理员会和产品经理、开发负责人和测试负责人沟通达成一致,然后在SVN中完成相应的设置。对于一些比较大的任务,需要多个人协同完成,可以为此开分支,分支也由配置管理人员创建,然后要求开发人员在分支上工作,完成相应任务,同时控制修改代码之后的提交。对于分支版本,只有符合本次版本要求的分支才允许合并到主干。这个工作是配置管理员和敏捷团队协作完成的。配置管理实践中最重要的是要摒弃原来所有的控制思想,让配置管理员作为敏捷项目团队中的一员,和团队共同协商如何管理代码、管理变更,而不像实施CMMI过程中有各种控制和审批环节。

    3.敏捷中实施Code Review(代码走查)

    技术评审活动是不管是否实施敏捷项目管理都需要进行的一种活动,很多人从来没有搞清楚什么是技术评审、什么是管理评审。技术评审包括需求评审、设计评审、代码Review、测试用例评审等和项目直接结果相关的工程活动的评审。管理评审指的是敏捷项目管理的三个仪式:Sprint规划会、每日例会和Sprint评审会。传统项目管理中的项目立项评审、里程碑评审和验收评审也属于管理评审。简单地总结,技术评审是针对软件工程活动的评审,其目的是通过缺陷预防提升软件的质量,管理评审是针对阶段活动是否可认定为结束、下阶段如何开始,其目的是项目管理活动是否有效,交付的成果是否可接受。

    如果借助敏捷项目管理的思想“交付可用的软件”,技术评审在敏捷活动中显得尤为重要,从评审的正式程度上划分,技术评审分为正式评审、技术审查和代码走查三种类型,如下表所示。

    评审种类

    计划

    准备

    会议

    修正

    确认

    Inspection(正式评审)

    Technical Reviews(技术审查)

    Walkthrough(代码走查)

    正式评审通常由项目经理主持,邀请项目的核心成员和外部有经验的专家参加,目的在于定位并消除软件中的缺陷。技术审查或称内部评审,通常由技术负责人召集相关人员参加,一般是在模块或功能完成时进行,目的在于通过对交付模块或功能的技术审查,提出改进意见。代码走查又称代码走读,由代码作者来组织,主要是代码质量分析和编程规则检查。一般是在模块或功能完成的早期进行,作者有一定的想法时,希望从其他开发者那里获得一些帮助或补充。由作者主持,目的是进行缺陷预防,提高代码的质量,很多公司已经成功地实施了Code Review和结对编程。

    总结第一轮实施敏捷的试点项目,并没有要求实施代码走查活动,项目负责人和开发人员也没有意识进行Code Review。要么是找借口说进度太紧张时间不够用,要么是不知道如何进行代码走查。第一种纯粹是意识问题,要回答不知道怎么进行代码走查的问题则从代码走查的种类开始着手。代码走查分为两种:一种是交叉代码审查,自己的代码由他人来检查,就像检查作业一样;另一种是代码会审,就是以会议的形式,大家共同审核代码的质量。代码走查主要审查的内容包括:是否符合代码规范,确保所有人写的代码基本一致并符合代码规范;代码满足基本用户故事的要求,检查代码的逻辑实现,确认能实现用户故事;代码满足性能等非功能性需求,非功能性需求一般需要借助一定的工具和Code Review人员的能力,针对编码中对于性能影响的瓶颈给出解决方案;代码简化,提高代码的可读性,能够用公用的方法和公用API实现,则无须每人定义自己的实现代码。

    随便抽出某开发人员的1000行代码检查的结果是:代码注释不充分,很多实现逻辑的类和方法没有注释;有些代码性能差,频繁地读/写磁盘I/O;有些代码虽然实现了功能需求,但从逻辑上写得太死,不便于扩展;在约定使用统一代码的写日志功能代码作者定义了自己的代码来实现。看来为了提高质量,代码走查是实施敏捷项目管理一定要执行的工作。

    4.被修订的测试报告

    测试报告是集成测试阶段每天都需要测试工程师编写的一份重要的信息沟通工具,它的目的是让团队所有成员了解当前Sprint交付软件的质量情况,每个开发人员身上有多少未解决的Bug,以及交付模块的质量情况。回顾试点项目的项目测试报告,大概是从百度上搜索的模板,冗长而不知所云。报告中什么编写目的、背景、测试对象、测试概要、测试用例、测试环境等,光标题就会让人眼花缭乱。从正规性上讲,这样的测试报告提交给最终用户无可厚非,但是给团队内部看就没必要这样讲求全面性和规范性了。再引用敏捷思想“可用的软件重于完备的文档”。所以修订测试报告应该是为团队减轻负担、提高沟通效率的一项优先级非常高的优化活动。

    问问团队需要什么样的报告。产品团队回答需要了解当前软件的质量来决策是否可发版,以及有些不好解决的缺陷拿出来让团队共同来决策Bug的处理策略。研发团队回答需要了解每个人身上有多少个未解决的缺陷,Bug整体解决情况和各模块的质量。测试团队关注的是Bug整体解决情况及分解下的按模块、按人员缺陷情况。统一思想后的测试报告包括一个测试情况的基本总结和三个部分。

    基本情况总结是整个测试报告中最重要的部分,应该用粗体和红色来描述。要求尽量用一两句话描述清楚当前测试的总体情况。例如,当前测试遇到未解决的严重级别缺陷大于3个,不符合发版需求,其中组件下载功能如果点击取消,必崩。第一部分是Bug移除率的统计,其中累计移除率是了解当前Bug整体解决情况的最好的说明,如下表所示为2010年9月23日某项目测试统计数据。

    日期

    当前

    遗留

    本日

    新增

    本日

    移除

    本日新增未解

    累计

    新增

    累计

    移除

    本日

    移除率

    累计

    移除率

    9/14

    120

    87

    80

    58

    314

    194

    92.0%

    61.8%

    9/15

    136

    83

    67

    58

    397

    261

    80.7%

    65.7%

    9/16

    135

    81

    83

    38

    478

    343

    102.5%

    71.8%

    9/17

    105

    47

    76

    29

    525

    420

    161.7%

    80.0%

    9/18

    107

    87

    84

    45

    612

    505

    96.6%

    82.5%

    9/21

    139

    73

    41

    45

    685

    546

    56.2%

    79.7%

    9/22

    137

    67

    69

    50

    752

    615

    103.0%

    81.8%

    9/23

    152

    71

    49

    58

    823

    671

    69.0%

    81.5%

    成功实施敏捷项目管理的团队一定有疑问,为什么实施敏捷后还有集成测试阶段,看上面的数据为什么质量会那么差,似乎和敏捷倡导的交付可用的软件有冲突。带着这些“十万个为什么”不妨思考一下。

    没有实施代码走查导致了大量缺陷,造成的直接结果是必须有个集中测试的阶段来把Bug找出来,每个功能和功能之间并不是独立的,开发人员在开发过程中并没有及时沟通导致了接口不一致等诸多Bug,产品人员没有及时确认交付的功能或模块是否可用甚至提出一些变更也导致了一些缺陷。如此多的原因导致这么多缺陷已经解释了上面的为什么,结论是如果敏捷项目管理实施成这样,基本上可以界定为是一场“形似而神不似”的失败的敏捷尝试了。但也可以肯定的是,这份测试数据总结对团队了解项目当前的总体质量起到了一目了然的作用。

    第二部分为Bug人员分布,第三部分为Bug模块分布,分别是按人员和按功能模块的缺陷数据总结。按人员的分布可以看出每个人当日解决的Bug数和剩余Bug数,便于提醒团队及时地解决Bug或者相互协助。按模块的Bug数总结便于提醒团队哪个模块的Bug多,除了了解模块的质量外还有助于提示团队及时进行代码走查来彻底解决质量问题。

    5.发布规则,绝不让步

    经过再一轮的组织级探索,让团队对于敏捷项目管理的基本原则有了更深入的认识。软件开发的残酷现实告诉我们,即使在敏捷项目管理框架下,没有规则的软件开发过程带来的只可能是无法预料的结果。不管是多么有经验的项目团队,在“响应变化胜于遵循计划”一项上都难以做到。一次次失败的教训告诉我们,我们需要在敏捷框架下设定一些基本规则,而在这些基本规则面前,在保证敏捷思想的前提下不能向规则让步。

    软件可用规则:上述的代码走查和测试数据告诉我们,在很多情况下我们交付的用户故事可用实际上是带有很多缺陷的,即使强调了PCT原则,团队交付的功能模块还是不完全可用,所以严格的方法是在燃尽图统计时,所有未完成的(即使是P和C状态都完成了的功能)都不进行统计,这和传统的“0-100”进度统计法则一致。让任何一个团队成员都知道积极参与,因为每一个功能交付如果说可用就一定要可用。

    目标导向原则:目标导向是充分调动员工工作积极性的最有效的方法,每个目标都设定卓越和及格的标准,在制订敏捷计划时,就需要明确项目如何做到卓越,并让指标认领到个人。例如,手机端每个滑屏操作的卓越标准是任意滑动的展现在0.6秒以下全部完成。对于开发者来说,近期的Sprint目标总是比远期目标来说更容易看到和达到,这会使每一个Sprint员工的工作效率维持在一个较高的水平。

    代码提交原则:很多开发人员在提交代码到配置管理系统时往往不注意是否通过了单元测试和自己代码的质量,这样会给其他人员带来或多或少的麻烦。所以为了提升团队效率,代码的提交必须满足两个硬条件,其一是提交的代码必须经过自己的单元测试,其二是确保提交代码后整体代码可编译通过。在这个原则的基础上,如果能自动化完成的工作绝对要减少人工干预,例如,持续集成和自动化测试尽量按策略自动完成。

    有话好好说原则:项目成员理解和赞同用户故事的范围、项目目标吗?开发人员大多数时间都不喜欢发表自己的看法和言论,大家不发表言论意味着他们认同项目范围和目标吗?这一点在项目沟通中极为重要,敏捷教练一定要问每个人,让每个人表达自己的观点,让大家有话好好说,有话桌面上说,不可认为不发言就认为是同意。在对项目目标没有一个共同认识的前提下,团队是不可能成功的。

    文档极简原则:敏捷思想并不鼓励书写文档。敏捷宣言也宣告“可用的软件重于完备的文档”,但如果一个软件是长期更新和维护的,还是需要必要的文档来将所有有价值的历史信息记录下来的。你如果刚加入一个敏捷团队来接手一个已经迭代了9个Sprint的软件,如果什么都没有你从哪里下手?但是不希望文档过于庞大,能把用户故事的关键点、设计的关键点记录下来就够了,特别是代码每次变更必须用注释描述清楚。

    精英团队原则:众所周知国内软件的成熟度偏低,一个公司能数出几个好的产品经理?又有多少技术高手?其实资源很有限。如果实施敏捷项目管理,必须抱着精英团队的原则,不鼓励团队规模过大。团队规模过大,按照n(n-1)/2的沟通渠道计算公式,沟通成本增加,效率极大降低。特别是很多需要技术难点公关比较多的项目,人数多根本解决不了任何问题。

    总之,在不违背敏捷思想的前提下,一些必要的规则是保证项目目标能够达到卓越的必要约束,也是促进团队建设和高效协作的基础。

    作者简介

    陈勇:在工作的17年间,曾任其程序员、项目经理、事业部总监、副总经理、咨询师等各种技术与管理岗位。开发中获得的一线工程经验和CMMI/FPA功能点估算/敏捷开发等跨领域知识,令其可以更广的视角来理解敏捷开发。

       当前他作为产品经理、架构师带领一个小型团队,从事“火星人敏捷开发在线平台”的研发工作。很多课程与咨询中的最佳实践,均来自于其之前及当前参与的实际项目的一线实践。本书收录的文章就是他们在实际开发过程中,同时应用敏捷开发的用户故事和功能点估算中的功能点时的实际经验总结。

       日常工作与培训之余,陈勇在其博客http://blog.csdn.net/cheny_com上总结编写了300多篇系列文章,点击量150万次,其中200篇以上是敏捷开发相关的文章,力求逐一解决敏捷开发中的一些似是而非的问题,为一线工作人员及敏捷推广者提供完整透彻的应用思路和方法。

     

    杜伟忠:中国人民大学管理学硕士,京东商城敏捷教练,精通Scrum、Kanban、XP等敏捷实践。10年电信软件开发经验,6年敏捷实践经验,其中有3年教练经历。作为教练指导团队超过200人,目前专注于互联网公司敏捷的推广和实施。

     

    冯国馨:网名“谷雨霖”。天津大学工学博士、PMP  联合永道高级副总裁兼CTO

    PMBar IT项目管理实践公益社区创始人、天津大学北京校友会秘书长

    曾任神州数码网络研发中心副总经理、质量管理部总经理,现任联合永道高级副总裁兼CTO、联合创始人。美国项目管理学会协会PMI会员、中国国家外专局资深专家、中国系统与软件过程改进协会主任专家会员、中国计算机学会软件工程师工作委员会专家组成员、国家应用软件产品质量监督检验中心特聘专家。长期从事项目管理、产品研发、持续改进与团队管理,对教育信息化建设有一定见解。创办IT项目管理实践公益社区www.pmbar.net,长期积极活跃在CSPI、CSDN CTO俱乐部、IT168等IT管理社区,与用友集团、阿里巴巴集团、盛拓传媒、搜狐集团、安博教育集团、神州数码集团等多家IT单位多次开展沙龙交流活动。

     

    王立杰:敏捷爱好者、实践者,独立培训师,专注Scrum与XP。2006年开始探索敏捷,应用敏捷,于2009年与许舟平合作出版国内第一本小说体敏捷项目管理图书《敏捷无敌》;2010年进入敏捷咨询培训领域,为诺基亚、北电、爱立信、VMWare、阿尔卡特-朗讯等多家公司提供服务,曾在AgileChina、ScrumGathering、AgileTour等行业会议发表多次主题演讲。

     

    许舟平:本一北国布衣,求学于西,工作于都,躬耕于代码十余载,苟全技术于IT间,不求闻达于海内。

    亲实践,远空谈,此敏捷之所以兴隆也;实践者,敏捷之本。盖闻流程者莫高于Scrum,实践者莫高于XP,皆因敏捷而成名。今天下贤者智能,岂特西洋者乎?好友立杰,邀士十余,原始察终,见盛观衰,论考之行,历经春秋,终成此集。

    敏捷者,其行虽不轨于瀑布、CMMI等,然其言必信,其行必果,已诺必诚。周易曰:天下一致而百虑,同归而殊途。窃以为,敏捷之事,内立法度,务实践,修研发之具;外连横而协客户,则事可成已。至于XP、Scrum、Lean、Crystal等,各有所用,若欲循观其大旨,可阅此书。

    布衣之人,不害于政,不妨百姓,取与以时而行敏捷,仅愿读者有采焉。

     

    杨立东:PMP,美国加州州立大学富尔顿分校硕士,中欧国际工商学院EMBA,华中科技大学特聘教授。北京暴风科技股份有限公司董事、首席技术官。2011年第二批“中关村高端领军人才聚集工程” 科技创新人才。发表学术论文4篇。曾从事过6年一线Java开发工作,作为项目经理带领过多个大型软件项目,2006年开始从事CMMI咨询和评估工作,服务过的软件企业超过30家,多次举办项目管理,软件度量,敏捷项目管理的公开课,培训人数超过15000人。2008年开始专注于公司级管理工作,2010年开始总结自己多年的研发管理经验,专注于互联网公司敏捷项目管理的推广和实施。

     

    杨瑞:个人简介:厦门英睿信息科技有限公司联合创始人,目前致力于敏捷的推广,研发管理咨询、培训及移动开发。

    10年软件工程管理经验,在基于传统和敏捷的开发管理方面具有丰富经验。曾任三五互联产品技术中心总监、福州网龙程序中心高级经理等职位,擅长软件研发管理、过程改进咨询、培训及实施,精通CMM、CMMI及Scrum。

    2011、2012年ScrumGathering分享嘉宾,2011、2012年AgileTour厦门站&福州站组织者、分享嘉宾,Agile China2013程序委员会专家,厦门敏捷社区发起人、技术社区积极分子。

     

    张克强:思碧睿inspearit高级顾问,高级程序员、系统分析员、IPMP、CSM。

    本硕毕业于清华大学。曾在宝信软件担任过测试经理、EPG组长、项目总监,曾在Intel担任过QA Manager,曾在DNV担任过资深咨询师。

    在软件工程/系统工程方面拥有10年多经验,主要经历在组织过程改进、质量保证和测试方面,帮助组织参照CMM/CMMI/Agile/Scrum等进行改进,在软件开发技术方法论和流程管理两方面都积累了丰富的经验,熟悉OOAD,UML,TDD, 测试等等。

    媒体评论

    敏捷是一种方法,更是一种组织能力。那些不懂得敏捷不利用敏捷方法的研发团队,最终将在快速变化、竞争激烈的互联网环境中落败。拥抱敏捷吧,从现在开始!

    ——京东商城高级副总裁  李大学

     

    这是一本很好的讲敏捷的书,本书的作者们并没有生硬地罗列令人费解的理论,而是结合亲身的经历,给读者生动展现了敏捷在IT行业的各种应用场景,令人受益匪浅,非常值得一看。我们也可以从中了解到,任何一种工具或者方法应用到实际工作中时,都不能生搬硬套,而是需要根据具体所在的行业、公司的企业文化以及研发团队的状况进行适当调整,亦可以称之为“本土化”——通过在实践中不断的解决问题,持续优化,使其更适用,更实用,真正的帮助到团队。

    ——汽车之家CTO  廖志强

    前言

    前些日子,有人在微博上发文说,现在IT界有三大俗:云计算、大数据、敏捷,这从一个侧面反映出了敏捷的热度!如果你最近一年内参加过各类IT过程改进大会、测试大会、研发管理大会、案例研讨大会,一定会发现有很多人在讲敏捷、谈敏捷,而且占据的场次越来越多。以前是我们这些所谓的敏捷狂热分子在讲,现在连一些CMMI/PMP死硬分子也加入进来讲。敏捷让以前的CMMI/PMP阵营不得不做出调整,PMP搞了敏捷的认证,CMMI新出了1.3版,据说里面有97处提到了敏捷……这从另外的角度说明敏捷的确已经入“俗”。

    中国人素来讲究雅俗共赏,在这个越来越“俗”的过程中,我们该怎么保持那份“雅”呢?希望大家在看热闹、参与热闹的同时,能够冷静地思考,敏捷到底能为我们带来什么?我们该如何变得敏捷?敏捷又将何去何从?

    大师们也在思考,2011年,敏捷10年回顾的时候,将“追求技术卓越”放在了第一的位置;10年之后,敏捷又将如何呢?著名敏捷大师MikeCohn认为:“在接下来的10年,面向对象世界中发生的事情会再次出现,即我们将不再讨论敏捷。不久前我们不再讨论对象了,因为它们已经胜出,没有人再会参加针对面向对象的大型辩论。当然,还有一些应用我们不使用对象,比如有严格性能要求的应用,也有些项目是用非OO语言开发的。但即使在这些案例中,我也怀疑开发的代码仍然受到对象的影响。我希望敏捷也能达到这一点,我们不再讨论敏捷,不再说‘敏捷软件开发’,我们仅仅说‘软件开发’,当然一定是敏捷的。没有人会问我编写的Ruby代码是否面向对象,因为这毋庸置疑;我希望某一天也没有人问我项目中是否使用了敏捷,这也将会毋庸置疑。”

    在过去几年中,我们给客户做敏捷培训时,收集到的最多的反馈之一,莫过于学员想听到更多的敏捷实施案例。于是,慢慢地就有了收集各类敏捷实施案例的想法,并日渐强烈起来。毕竟,每个人都有偷窥别人隐私的好奇心,不然Twitter、微博也就不会这么火了。同理,正在实施敏捷的人,无论自己做得好的,做得不好的,其实都希望看到同行是怎么做的。

    冯国馨,作为PMBar IT项目管理公益实践社区发起人,在社区内外的各种敏捷分享和交流过程中,看到大家也非常希望了解、学习和探讨国内不同IT行业、不同特点IT企业敏捷开发的真实案例。加之,2011年8月PMBar社区推出的第一部实践案例书籍《IT项目管理那些事儿》在社会上反响热烈,至今图书热卖万余册。这些极大地增强了我们进一步开展敏捷实践案例书籍撰写的信心!

    于是,在王立杰的协调下,PMBar社区内外的十几位敏捷专家决定共同分享自己的敏捷实践案例,希望通过出书使行业内的敏捷实践者或敏捷观望者有所借鉴和体悟。

    本书采用的是叙事的风格,通过分享每个敏捷实践者自身的实践案例,为读者展现一个个鲜活的敏捷实施过程,展示敏捷团队的成长烦恼和喜悦,从而和读者达到共鸣。这是一个百花齐放、精彩纷呈的故事集,就像《一千零一夜》一样,有十几位作者,他们中有来自国际著名IT公司的敏捷专家、有来自国内著名电商的敏捷教练、有来自大型国有企业的IT总监、有民营高科技企业技术管理者,有纯粹的敏捷实践者、也有CMMI/敏捷融合实践者等,他们以不同的经历、用不同风格的言语,为我们描述一个又一个精彩的敏捷开发故事。

    感谢本书编委会全体成员(王立杰、冯国馨、许舟平、陈勇、杨立东、张克强、杨瑞、杜伟忠、郑贺宸、蔡阿彬、胡峰、范佳莹、马越、史昀)的共同努力,因为他们的努力才有了这本书的诞生。感谢电子工业出版社博文视点的张月萍,她的“博文视点除了盈利的任务外,还承担着教育用户、传播思想的重任!”一句话为《敏捷开发一千零一夜》这本书画龙点睛。我们希望这本书能启迪正在或者准备开展敏捷实践的读者,如果它帮助你加快了敏捷步伐,那就是我们最大的欣慰。

    再次,真心感谢曾经为此书劳心劳力的各位朋友,愿天下人幸福安康。

    编者

    展开全文
  • 测试驱动开发敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行...

    这些知识之前就了解了一点,还没来得急总结,现在总结一下。

    1. 首先了解一下这三个开发模式都是什么意思:

    • TDD:测试驱动开发(Test-Driven Development)

    测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把需求分析,设计,质量控制量化的过程。TDD首先考虑使用需求(对象、功能、过程、接口等),主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。

    • BDD:行为驱动开发(Behavior Driven Development)

    行为驱动开发是一种敏捷软件开发的技术,它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。主要是从用户的需求出发,强调系统行为。BDD最初是由Dan North在2003年命名,它包括验收测试和客户测试驱动等的极限编程的实践,作为对测试驱动开发的回应。

    • ATDD:验收测试驱动开发(Acceptance Test Driven Development)

    TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。


    2. 软件开发过程中最常见的两个问题

    需求和开发脱节:

    • 用户想要的功能没有开发
    • 开发的功能并非用户想要
    • 用户和开发人员所说语言不同
    开发和测试脱节:
    • 开发和测试被认为割裂
    • 从开发到测试周期过长
    • 测试自动化程度低
    3. 如何解决上面说的两个问题
    使用BDD和ATDD可以解决需求和开发脱节的问题,首先他们都是从用户的需求出发,保证程序实现效果与用户需求一致。
    这个过程可以使用基于BDD的自动化测试工具Cucumber。


    解决开发和测试脱节主要从以下几个方面入手:
    • 开发的全过程都要贯穿测试:单元测试,集成测试和系统测试
    • 测试需要自动化
    • 所有测试通过,开发才算完成
    • 持续集成,保证每一次集成系统都能运行
    4. 如何进行CI(Continuous Integration)也就是持续集成
           ● 持续提交代码 (Check-in)
                    ○ 一天之中多次提交
           ● 持续构建代码 (Build)
                    ○ 保证在任何时刻代码是可以继续开发的
           ● 持续部署代码 (Deploy)
                    ○ 保证始终有一个可以部署的版本
           ● 持续测试代码 (Test)
                    ○ 每次提交均执行单元测试
                    ○ 每天一次或数次集成测试
                    ○ 每天一次或数次系统测试
    持续集成工具:Jenkins


    5. 一张图比较TDD与ATDD

    展开全文
  •  摘要:软件工程的开发过程中有两种截然不同的管理和开发体系,一种是基于“瀑布模型”的预设性传统软件工程,另一种是轻量级的适应性敏捷软件开发,本文简单阐述传统软件工程的开发方法与敏捷软件开发的异同,并...

    敏捷软件开发与传统软件工程概述比较

    翁松秀

    北京航空航天大学计算机学院

      摘要:软件工程的开发过程中有两种截然不同的管理和开发体系,一种是基于“瀑布模型”的预设性传统软件工程,另一种是轻量级的适应性敏捷软件开发,本文简单阐述传统软件工程的开发方法与敏捷软件开发的异同,并通过“瀑布模型”和SCRUM方法的比较来探析传统软件工程与敏捷软件开发的异同。最后得出结论,把传统软件工程和敏捷软件开发相结合,将软件架构“颗粒化”,在简单可快速交付的敏捷软件开发中嵌套系统的传统软件开发方法,实现预见性和适应性折中。

    关键词:敏捷软件开发;传统软件工程;瀑布模型;SCRUM方法;嵌套;颗粒化

      0 前言

      随着计算机的发展,对软件的需求越来越大,软件的规模也变得越来越大,结构越来越复杂,软件开发管理困难而复杂,在这个“软件危机”背景下产生的传统软件工程,用工程化的方法构建和维护有效和高质量的软件。暂时解决了软件的兵荒马乱时代,但随着社会和科技的发展,对软件的需求变化越来越快,传统的软件工程很难再适应瞬息万变的客户需求,敏捷软件开发应运而生,其轻量级、简单、可快速交付、适应性强收到开发团队的青睐,与传统软件工程并肩,形成软件工程中的两大开发体系。

      1 传统软件工程

    1.1 传统软件工程概述

      基于“瀑布模型”的传统软件开发方法中,以软件架构(software architecture)为核心,采用结构化的设计和分析方法将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。并规定他们自上而下,相互衔接的顺序,如同瀑布的流水一般,各个阶段的通过文档相互流通。前期就要设计好整个软件大厦的框架来指导和支撑后面各个方面的开发和维护工作,后面再根据前期设计的蓝图来逐步实现。由架构师完成软件架构设计,开发人员再根据软件大厦的蓝图进行软件开发。这种开发方法的优点是,超前的预见性和每一阶段都要通过严格的审查才能进行下一个阶段,保证了软件的质量。缺点是,软件的框架一旦确定下来就很难改变,甚至会牵一发而动全身,难以适应变化莫测的客户需求。由于各个阶段要自上而下相互衔接,各个阶段的沟通要通过大量臃肿、复杂的文档来传递信息。

      1.2 瀑布模型

      瀑布模型是Winston Royce1970年提出的一种软件开发模型,瀑布式开发是一种传统的计算机软件开发,是最典型的预见性软件开发方法,严格遵守计划、分析、设计、编码、测试、维护的步骤。阶段之间通过文档流通,每个阶段结束时要进行严格的审查,检查功能设计和实现是否符合上阶段流下来的文档的要求,如果不符合就逆流到上个阶段检查并修正,以此往复,直到流到最后阶段产品通过测试后进行发布以及运行期间的维护。

    • 瀑布模型开发过程(如图)

      • 三个阶段:定义阶段、开发阶段和维护阶段。开发阶段架构师要有预见性地分析客户现在的需求以及以后可能变动的需求,设计规划好大量的功能需求和非功能需求,尽可能多地满足客户后面需求的变动,避免日后重构软件框架带来的成本亏损。设计包括UML图,API接口,数据库表等。开发阶段开发人员根据架构师的对客户需求分析以后设计的蓝图进行软件的开发和测试,实现用户的需求。运维阶段开发团队根据用户使用软件的体验、反馈、软件存在的BUG和新增功能需求对软件进行维护,保证软件在保证鲁棒性的前提下能尽可能地满足客户的需求。
      • 六个流程:制定计划、需求分析、软件设计、程序编写、软件测试和运行维护。
    • 瀑布模型的特点
      • 强调文档。瀑布模型每个阶段之间的沟通和交流就是文档,上一个阶段的输出就是下一个阶段的输入,文档就是前后阶段衔接的介质。缺少开发人员之间面对面的沟通与交流,造成文档臃肿现象。
      • 结构明显。按需求分析将整个工程划分为完整的阶段集合,每一个阶段都有明确的检查点,当出现问题可以使用顺藤摸瓜式往上检查。当一个阶段结束后通过严格审查,就可以只关注下个阶段,出现问题再逆流检查。

      2 敏捷软件开发

      1.2 敏捷软件开发概述

      2001年由17位业界专家构成的敏捷开发联盟成立,联盟起草了敏捷宣言:个体与交互胜过过程和工具;可用的软件高于复杂的文档;客户的合作胜过合同的谈判;响应变化胜过遵循计划。敏捷软件开发是一组重视人的主观能动性和开发人员、管理层和产品负责人的沟通,通过迭代式和增量式软件,追求便捷,可快速交付,及时响应客户需求变动的软件开发管理方法。

      敏捷软件开发方法体系主要包括:SCRUMXP(极限编程)、CRYSTAL(水晶编程)、PDD(特性驱动开发)等。敏捷软件开发的一个精髓就是“刚刚够(Just enough)”思想。用逐步实现的思想替代完整构架,每一步的需求和人员及其沟通、开发成本都刚刚好,通过不断地迭代,在迭代过程中响应客户需求的变化,实现最紧致成本,体现“刚刚好”思想。同时对每次迭代的反馈进行讨论和思考,总结经验和吸取教训。

      2.2 SCRUM方法

      在敏捷软件开发中,软件项目被切分成很多个子项目,通过选取优先级较高的一组子项目作为敏捷迭代的球心进行迭代,每次迭代都有明确的需求、目标、人员、并且每次迭代之后都要有可交付的产品。就好比从山顶滚雪球,选取优先级较高的需求作为首次迭代的球心,经过增量式迭代,每次迭代加带一定的需求滚下山,下山就可以形成可交付的产品。

    • 三个角色:管理层(Scrum Master)、产品负责人(Product Owner)和开发团队(Team)。
    • 三种工件:产品列表(Product Backlog)、迭代列表(Sprint Backlog)和燃尽图(Burn Down Chart)。
    • 四个会议:Sprint Plan MeetingSprint 计划会议)、Daily Scrum MeetingScrum每日会议)和Sprint Review MeetingSprint评审会议)和Sprint Retrospective MeetingSprint回顾会议)。

    • 五个步骤

        (1)Product Owner根据需求的优先级确定一个排序好的Product Backlog

        (2)Scrum Team通过Sprint Plan Meeting根据Product Backlog按优先级选出一组需求作为迭代的目标,即Sprint Backlog。这个阶段一般的时间是4周。

        (3)Scrum Team完成Sprint Backlog过程中需要每天都要进行Daily Scrum Meeting,每个人都要汇报所完成的进度和遇到的问题,总结经验,通过Burn Down Chart记录工作的整个过程。

        (4)当本次SprintSprint Backlog都实现完之后进行Sprint Review Meeting,这个会议中管理层和产品负责人以及开发团队都要参加,讨论本次Sprint交付的产品,以及根据产品负责人的需求变动及时调整。

        (5)最后进行Sprint Retrospective Meeting,回顾本次Sprint整个过程中开发遇到的问题,以及解决的方案,为下一轮Sprint做准备。

     

      3 结束语

      3.1 敏捷开发与软件架构的比较

      敏捷开发的优点是轻量级、简单、可快速交付,最大的特点是高度透明、检验和适应,注重开发团队之间以及开发团队与客户的及时沟通,主张响应需求变化,但是不够系统。

      传统软件架构的优点在于预见性和系统性,能在正式开发前预见软件的功能需求和非功能需求,最大的特点是重视文档和结构明显,主张固定流水开发,很难响应客户需求的变化,难以保证开发的灵活性。

      3.2 敏捷开发与软件架构的融合

      将具有系统性和预见性的软件架构嵌套到敏捷开发的每次轻量级的迭代中,将软件架构颗粒化,嵌套到整个敏捷开发,使软件工程兼具软件构架的预见性和敏捷开发的适应性,根据项目的大小来调整嵌套的程度,根据每次迭代项目的大小来选择不同的架构,实现敏捷开发与软件架构融合的双赢。

      参考文献:

    [1]王玉玺.浅谈敏捷软件开发.设计开发.2014

    [2]孙嘉瑞.敏捷开发方法综述.科技创新.2015

    [3]聂华北,沈剑翘.几种常见的敏捷软件开发方法综述.计算机系统应用.2008

    [4]王琼.敏捷软件开发过程研究及应用.技术探讨.2015

    [5]李声威,王爱景.敏捷开发与软件架构概述比较.万方数据.2015

    [6]孙宗旺,蓝金球.基于Web服务组合的敏捷软件开发研究.软件导刊.2015

    转载于:https://www.cnblogs.com/maya389069192/p/5947022.html

    展开全文
  • 本书是由京东、IBM、淘宝、SAP、暴风影音等IT名企专家——也包括博主本人——所编写的敏捷经验分享,都来自于真实的开发经历。既然叫做一千零一夜,就是希望实践者的故事永远讲不完,期待大家的参

    不知道大家是否还记得年初写的《软件工程四十年预测》一文,里边提到了“实践软件工程”的概念。也就是说未来引领软件工程的不再是少数大师,而很可能是在实践中不断摸索,或有经验或有教训或有心得的普通一线开发者和管理者。

    本书是由京东、IBM、淘宝、SAP、暴风影音等IT名企专家——也包括博主本人微笑——所编写的敏捷经验分享,都来自于真实的开发经历。

    敏捷开发的主体,不是理论也不是大师,而是所有不执着于定论,勇于不断摸索最好方法的一线人员。书名叫做一千零一夜,就是希望实践者的故事永远讲不完,期待大家的参与和分享。

    京东,亚马逊、当当、互动出版社均有销售,以下内容节选自京东的介绍(今天图书上了京东的首页,在“新书速递-科技”栏目下)。

    内容简介

      《敏捷开发一千零一夜》以多位作者的亲身经历,再现真实的敏捷实施过程,描述各个企业在实施敏捷的过程中,遇到的种种问题、解决的思路及最终得到的经验与教训。这本案例集从不同的视角,为读者展示从大型互联网企业到初创公司、从大型国企到独资外企、从典型的甲方到第三方咨询公司的敏捷历程。这里面既有大的组织的敏捷转型,也有一个小团队或个人的敏捷历程,还涵盖某个敏捷实践或工具的应用描述。
      本书的特色在于由真实实践提炼,对正在实施敏捷的读者具有很高的参考价值。

    作者简介

        陈勇,在工作的17年间,曾任其程序员、项目经理、事业部总监、副总经理、咨询师等各种技术与管理岗位。开发中获得的一线工程经验和CMMI/FPA功能点估算/敏捷开发等跨领域知识,令其可以更广的视角来理解敏捷开发。

        当前他作为产品经理、架构师带领一个小型团队,从事“火星人敏捷开发在线平台”的研发工作。很多课程与咨询中的最佳实践,均来自于其之前及当前参与的实际项目的一线实践。本书收录的文章就是他们在实际开发过程中,同时应用敏捷开发的用户故事和功能点估算中的功能点时的实际经验总结。
        日常工作与培训之余,陈勇在其博客http://blog.csdn.net/cheny_com上总结编写了300多篇系列文章,点击量150万次,其中200篇以上是敏捷开发相关的文章,力求逐一解决敏捷开发中的一些似是而非的问题,为一线工作人员及敏捷推广者提供完整透彻的应用思路和方法。


        杜伟忠,中国人民大学管理学硕士,京东商城敏捷教练,精通Scrum、Kanban、XP等敏捷实践。10年电信软件开发经验,6年敏捷实践经验,其中有3年教练经历。作为教练指导团队超过200人,目前专注于互联网公司敏捷的推广和实施。


        冯国馨,网名“谷雨霖”。天津大学工学博士、PMP 联合永道高级副总裁兼CTO
        PMBar IT项目管理实践公益社区创始人、天津大学北京校友会秘书长
        曾任神州数码网络研发中心副总经理、质量管理部总经理,现任联合永道高级副总裁兼CTO、联合创始人。美国项目管理学会协会PMI会员、中国国家外专局资深专家、中国系统与软件过程改进协会主任专家会员、中国计算机学会软件工程师工作委员会专家组成员、国家应用软件产品质量监督检验中心特聘专家。长期从事项目管理、产品研发、持续改进与团队管理,对教育信息化建设有一定见解。创办IT项目管理实践公益社区www.pmbar.net,长期积极活跃在CSPI、CSDN CTO俱乐部、IT168等IT管理社区,与用友集团、阿里巴巴集团、盛拓传媒、搜狐集团、安博教育集团、神州数码集团等多家IT单位多次开展沙龙交流活动。


        史昀,2004年毕业于上海交通大学,同年拿到国家高级程序员证书,2009年获得PMP认证,2010年作为CMMI评估组成员参加CMMI 3级评估,典型的技术型管理人员,沉浮于软件开发行业,专注于通信、商业类软件研发,为国内外大型企业客户提供咨询、实施等解决方案,关注软件工程及相关领域的研究与培训。现就职于一家大型外资ERP软件厂商,从事财务软件、软件生命周期以及LEAN相关内容的研究。


        王立杰,敏捷爱好者、实践者,独立培训师,专注Scrum与XP。2006年开始探索敏捷,应用敏捷,于2009年与许舟平合作出版国内第一本小说体敏捷项目管理图书《敏捷无敌》;2010年进入敏捷咨询培训领域,为诺基亚、北电、爱立信、VMWare、阿尔卡特-朗讯等多家公司提供服务,曾在AgileChina、ScrumGathering、AgileTour等行业会议发表多次主题演讲。


        许舟平,就职于IBM公司。本一北国布衣,求学于西,工作于都,躬耕于代码十余载,苟全技术于IT间,不求闻达于海内。
        亲实践,远空谈,此敏捷之所以兴隆也;实践者,敏捷之本。盖闻流程者莫高于Scrum,实践者莫高于XP,皆因敏捷而成名。今天下贤者智能,岂特西洋者乎?好友立杰,邀士十余,原始察终,见盛观衰,论考之行,历经春秋,终成此集。
        敏捷者,其行虽不轨于瀑布、CMMI等,然其言必信,其行必果,已诺必诚。周易曰:天下一致而百虑,同归而殊途。窃以为,敏捷之事,内立法度,务实践,修研发之具;外连横而协客户,则事可成已。至于XP、Scrum、Lean、Crystal等,各有所用,若欲循观其大旨,可阅此书。
        布衣之人,不害于政,不妨百姓,取与以时而行敏捷,仅愿读者有采焉。


        杨立东,就职于暴风影音公司。PMP,美国加州州立大学富尔顿分校硕士,中欧国际工商学院EMBA,华中科技大学特聘教授。北京暴风科技股份有限公司董事、首席技术官。2011年第二批“中关村高端领军人才聚集工程” 科技创新人才。发表学术论文4篇。曾从事过6年一线Java开发工作,作为项目经理带领过多个大型软件项目,2006年 开始从事CMMI咨询和评估工作,服务过的软件企业超过30家,多次举办项目管理,软件度量,敏捷项目管理的公开课,培训人数超过15000人。2008年开始专注于公司级管理工作,2010年开始总结自己多年的研发管理经验,专注于互联网公司敏捷项目管理的推广和实施。


        杨瑞,个人简介:厦门英睿信息科技有限公司联合创始人,目前致力于敏捷的推广,研发管理咨询、培训及移动开发。
        10年软件工程管理经验,在基于传统和敏捷的开发管理方面具有丰富经验。曾任三五互联产品技术中心总监、福州网龙程序中心高级经理等职位,擅长软件研发管理、过程改进咨询、培训及实施,精通CMM、CMMI及Scrum。
        2011、2012年ScrumGathering分享嘉宾,2011、2012年AgileTour厦门站&福州站组织者、分享嘉宾,Agile China 2013程序委员会专家,厦门敏捷社区发起人、技术社区积极分子。


        张克强,思碧睿inspearit高级顾问,高级程序员、系统分析员、IPMP、CSM。
        本硕毕业于清华大学。曾在宝信软件担任过测试经理、EPG组长、项目总监,曾在Intel担任过QA Manager,曾在DNV担任过资深咨询师。
        在软件工程/系统工程方面拥有10年多经验,主要经历在组织过程改进、质量保证和测试方面,帮助组织参照CMM/CMMI/Agile/Scrum等进行改进,在软件开发技术方法论和流程管理两方面都积累了丰富的经验,熟悉OOAD,UML,TDD, 测试等等。

    目录

    第一篇  组  织  篇
    第1章  暴风敏捷项目管理实践
    一、暴风的项目危机
    二、组织级的敏捷初体验
    三、再次组织级探索
    四、持续优化的力量
    五、组织改进中人的因素
    第2章  淘宝的敏捷实践与过程改进
    一、背景介绍
    二、不同背景下的解决方案
    三、ScrumMaster心得
    四、敏捷与过程改进
    五、工具的支持
    第3章  从CMMI5到敏捷
    一、案例背景
    二、敏捷导入过程
    三、敏捷优化改进过程
    四、整体回顾
    第4章  从装甲兵团到特种部队
    一、引子
    二、实施过程
    三、反思

    第二篇  产  品  篇
    第5章  火星人一千零一夜
    一、第一个月:一个产品的诞生
    二、第二个月:框架优先,还是故事群优先
    三、第三个月:故事树
    四、第四个月:用户故事的颗粒度(上)
    五、第五个月:用户故事的颗粒度(下)
    六、第六个月:用户故事的分类
    七、第七个月:分类语法
    八、后记
    第6章  从敏捷到精益
    一、背景
    三、破窗理论
    四、敏捷宣言错了吗
    五、南辕北辙
    六、MVP才是王道
    七、跨越鸿沟
    八、小结

    第三篇  团  队  篇
    第7章  敏捷英雄传之火烧赤壁
    一、人物介绍
    二、故事梗概
    三、引子
    四、CEO孙权的故事:计划永远赶不上变化
    五、CTO周瑜的故事:究竟是变好,还是变得更烂
    六、产品经理太史慈的故事:一个大版本经理的困惑
    七、编码狂人凌统的故事:主刀,就是能上得天堂,下得地狱的主儿
    八、测试经理陆逊的故事:敏捷测试,就是明知不可为而为之
    九、产品集成主管甘宁的故事:持续集成的烦恼
    十、臭皮匠的话
    第8章  打造学习型自适应团队
    一、背景介绍
    二、团队实践过程
    三、回顾与反思
    第9章  从传统软件开发到敏捷的初体验
    一、背景
    二、迈出第一步
    三、对第一次迭代的改进
    四、关键的第三次迭代
    五、第四次迭代:低耦合软件设计
    六、总结
    第10章  敏捷在传统软件与互联网中的应用
    一、背景介绍
    二、敏捷实施过程
    三、回顾与反思

    第四篇  实  践  篇
    第11章  敏捷无它,唯持续改进
    一、背景介绍
    二、我与敏捷的第一次亲密接触
    三、敏捷原来是这样的
    四、第一个挑战
    五、团队的好奇心
    六、更多挑战
    七、团队的惯性
    八、镜子
    九、从一开始就要高标准
    十、TDD的争议
    十一、“道”与“术”
    十二、程序员文化
    十三、程序员与建筑工人
    十四、TDD不是目的,“拉”与“推”
    十五、Coding Dojo
    十六、让实践落地
    十七、程序员的产出
    十八、权威
    十九、认同权的建立:无私,勇于说不知道
    二十、成就感:点燃程序员的热情
    二十一、PDD:痛苦驱动开发
    二十二、排除障碍,创建舒适的技术环境
    二十三、投资回报率
    二十四、让领域模型裸奔
    二十五、架构
    二十六、你做什么就是什么(You are what you do)
    二十七、Scrum是不行的,如果只有Scrum
    二十八、做正确的事情 vs 正确地做事情
    二十九、问题和解决方案,5-whys
    三十、“为什么”
    三十一、估算(动词)很有帮助,但估算(名词)往往没有
    三十二、守破离
    三十三、测试优先
    三十四、QA vs QC
    三十五、分享:Wiki、博客、书籍、技术讨论、编程练习
    三十六、没有银弹,只有持续改进
    三十七、敏捷宣言
    第12章  网龙持续集成实践
    一、案例背景
    二、案例分享

    前言

      前些日子,有人在微博上发文说,现在IT界有三大俗:云计算、大数据、敏捷,这从一个侧面反映出了敏捷的热度!如果你最近一年内参加过各类IT过程改进大会、测试大会、研发管理大会、案例研讨大会,一定会发现有很多人在讲敏捷、谈敏捷,而且占据的场次越来越多。以前是我们这些所谓的敏捷狂热分子在讲,现在连一些CMMI/PMP死硬分子也加入进来讲。敏捷让以前的CMMI/PMP阵营不得不做出调整,PMP搞了敏捷的认证,CMMI新出了1.3版,据说里面有97处提到了敏捷……这从另外的角度说明敏捷的确已经入“俗”。
      中国人素来讲究雅俗共赏,在这个越来越“俗”的过程中,我们该怎么保持那份“雅”呢?希望大家在看热闹、参与热闹的同时,能够冷静地思考,敏捷到底能为我们带来什么?我们该如何变得敏捷?敏捷又将何去何从?
      大师们也在思考,2011年,敏捷10年回顾的时候,将“追求技术卓越”放在了第一的位置;10年之后,敏捷又将如何呢?著名敏捷大师Mike Cohn认为:“在接下来的10年,面向对象世界中发生的事情会再次出现,即我们将不再讨论敏捷。不久前我们不再讨论对象了,因为它们已经胜出,没有人再会参加针对面向对象的大型辩论。当然,还有一些应用我们不使用对象,比如有严格性能要求的应用,也有些项目是用非OO语言开发的。但即使在这些案例中,我也怀疑开发的代码仍然受到对象的影响。我希望敏捷也能达到这一点,我们不再讨论敏捷,不再说‘敏捷软件开发’,我们仅仅说‘软件开发’,当然一定是敏捷的。没有人会问我编写的Ruby代码是否面向对象,因为这毋庸置疑;我希望某一天也没有人问我项目中是否使用了敏捷,这也将会毋庸置疑。”
      在过去几年中,我们给客户做敏捷培训时,收集到的最多的反馈之一,莫过于学员想听到更多的敏捷实施案例。于是,慢慢地就有了收集各类敏捷实施案例的想法,并日渐强烈起来。毕竟,每个人都有偷窥别人隐私的好奇心,不然Twitter、微博也就不会这么火了。同理,正在实施敏捷的人,无论自己做得好的,做得不好的,其实都希望看到同行是怎么做的。
      冯国馨,作为PMBar IT项目管理公益实践社区发起人,在社区内外的各种敏捷分享和交流过程中,看到大家也非常希望了解、学习和探讨国内不同IT行业、不同特点IT企业敏捷开发的真实案例。加之,2011年8月PMBar社区推出的第一部实践案例书籍《IT项目管理那些事儿》在社会上反响热烈,至今图书热卖万余册。这些极大地增强了我们进一步开展敏捷实践案例书籍撰写的信心!
      于是,在王立杰的协调下,PMBar社区内外的十几位敏捷专家决定共同分享自己的敏捷实践案例,希望通过出书使行业内的敏捷实践者或敏捷观望者有所借鉴和体悟。
      本书采用的是叙事的风格,通过分享每个敏捷实践者自身的实践案例,为读者展现一个个鲜活的敏捷实施过程,展示敏捷团队的成长烦恼和喜悦,从而和读者达到共鸣。这是一个百花齐放、精彩纷呈的故事集,就像《一千零一夜》一样,有十几位作者,他们中有来自国际著名IT公司的敏捷专家、有来自国内著名电商的敏捷教练、有来自大型国有企业的IT总监、有民营高科技企业技术管理者,有纯粹的敏捷实践者、也有CMMI/敏捷融合实践者等,他们以不同的经历、用不同风格的言语,为我们描述一个又一个精彩的敏捷开发故事。
      感谢本书编委会全体成员(王立杰、冯国馨、许舟平、陈勇、杨立东、张克强、杨瑞、杜伟忠、郑贺宸、蔡阿彬、胡峰、范佳莹、马越、史昀)的共同努力,因为他们的努力才有了这本书的诞生。感谢电子工业出版社博文视点的张月萍,她的“博文视点除了盈利的任务外,还承担着教育用户、传播思想的重任!”一句话为《敏捷开发一千零一夜》这本书画龙点睛。我们希望这本书能启迪正在或者准备开展敏捷实践的读者,如果它帮助你加快了敏捷步伐,那就是我们最大的欣慰。
      再次,真心感谢曾经为此书劳心劳力的各位朋友,愿天下人幸福安康。
      编者

    展开全文
  • 今天是第二天了,周日拼多多的“BUG”可谓占据了各大版块头条,从技术角度分析,没什么好分析的……毕竟这其实不能算是一个技术BUG,要说也是市场操作不当留下的祸根。而那么多...
  • 笑谈PDD——仅为调侃

    2019-07-21 19:23:49
    中国是一个不擅长创造概念的国家,然而,在软件的世界里,中国却开创了一个新的名词——称之PDDPDD——Page-Driven Develop(页面驱动开发)。 2. 适从于企业的软件开发 中国大多数的公司是什么开发现状我不清楚...
  • 看一些文章会看到TDD开发模式,搜索后发现有主流四种软件开发模式,这里对它们的概念做下笔记。 TDD:测试驱动开发(Test-Driven Development) 测试驱动开发敏捷开发中的一项核心实践和技术,也是一种设计方法...
  • PDD正式批笔试

    2019-12-05 15:40:59
    为了准备实习面试三天速成了SQL(正如我所说,我的动力来源之一是DDL),正好收到了Pdd笔试,别人告诉我说一般是三道SQL一道ABtest一道业务题。我想着正好我速成了耶!结果,恩,原来我只是速成了基础。 这边整理...
  • DevOps技术发达的今天,PDD薅羊毛事件本不应该发生。 原本就不该出现这种无门槛的优惠券(等同于送钱),就算一定要发这张优惠券,应该发给特定用户目标群,不该让同一个人能薅几十万羊毛; 即使业务需求没...
  • PHP最新美化拼多多出码系统源码 pdd通道出码 拼多多渠道pdd支付安全稳定+详细教程 自己下载了研究看
  • PDD出码系统后台,对接三方支付/四方支付系统,需要研究的朋友可以自行下载。用户可以学习里面的编码思路,拓展系统
1 2 3 4 5 ... 20
收藏数 5,834
精华内容 2,333
关键字:

敏捷开发引进pdd概念