新書推薦：
《
粤行丛录（岭南史料笔记丛刊）
》
售價：HK$
80.2
《
岁月待人归：徐悲鸿自述人生艺术
》
售價：HK$
61.4
《
女人的中国医疗史：汉唐之间的健康照顾与性别
》
售價：HK$
103.8
《
资治通鉴熊逸版：第四辑
》
售價：HK$
470.8
《
中国近现代名家精品——项维仁：工笔侍女作品精选
》
售價：HK$
66.1
《
宋瑞驻村日记（2012-2022）
》
售價：HK$
115.6
《
汗青堂丛书138·帝国的切口：近代中国口岸的冲突与交流（1832-1914）
》
售價：HK$
127.4
《
人世事，几完缺 —— 啊，晚明
》
售價：HK$
115.6
|
| 編輯推薦： |
覆盖组织转型、产品管理、团队建设、工程实践，解析精彩过程，分享经验教训，揭示敏捷背后的奥秘。
汇集IBM、淘宝、京东、暴风影音等IT名企的敏捷专家经验分享。
|
| 內容簡介： |
本书以多位作者的亲身经历，再现真实的敏捷实施过程，描述各个企业在实施敏捷的过程中，遇到的种种问题、解决的思路及最终得到的经验与教训。这本案例集从不同的视角，为读者展示从大型互联网企业到初创公司、从大型国企到独资外企、从典型的甲方到第三方咨询公司的敏捷历程。这里面既有大的组织的敏捷转型，也有一个小团队或个人的敏捷历程，还涵盖某个敏捷实践或工具的应用描述。
本书的特色在于由真实实践提炼，对正在实施敏捷的读者具有很高的参考价值。
|
| 關於作者： |
陈勇，在工作的17年间，曾任其程序员、项目经理、事业部总监、副总经理、咨询师等各种技术与管理岗位。开发中获得的一线工程经验和CMMIFPA功能点估算敏捷开发等跨领域知识，令其可以更广的视角来理解敏捷开发。
当前他作为产品经理、架构师带领一个小型团队，从事“火星人敏捷开发在线平台”的研发工作。很多课程与咨询中的最佳实践，均来自于其之前及当前参与的实际项目的一线实践。本书收录的文章就是他们在实际开发过程中，同时应用敏捷开发的用户故事和功能点估算中的功能点时的实际经验总结。
日常工作与培训之余，陈勇在其博客http:blog.csdn.netcheny_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年多经验，主要经历在组织过程改进、质量保证和测试方面，帮助组织参照CMMCMMIAgileScrum等进行改进，在软件开发技术方法论和流程管理两方面都积累了丰富的经验，熟悉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章 网龙持续集成实践
一、案例背景
二、案例分享
|
| 內容試閱：
|
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评审会。传统项目管理中的项目立项评审、里程碑评审和验收评审也属于管理评审。简单地总结，技术评审是针对软件工程活动的评审，其目的是通过缺陷预防提升软件的质量，管理评审是针对阶段活动是否可认定为结束、下阶段如何开始，其目的是项目管理活动是否有效，交付的成果是否可接受。
如果借助敏捷项目管理的思想"交付可用的软件"，技术评审在敏捷活动中显得尤为重要，从评审的正式程度上划分，技术评审分为正式评审、技术审查和代码走查三种类型，如下表所示。
正式评审通常由项目经理主持，邀请项目的核心成员和外部有经验的专家参加，目的在于定位并消除软件中的缺陷。技术审查或称内部评审，通常由技术负责人召集相关人员参加，一般是在模块或功能完成时进行，目的在于通过对交付模块或功能的技术审查，提出改进意见。代码走查又称代码走读，由代码作者来组织，主要是代码质量分析和编程规则检查。一般是在模块或功能完成的早期进行，作者有一定的想法时，希望从其他开发者那里获得一些帮助或补充。由作者主持，目的是进行缺陷预防，提高代码的质量，很多公司已经成功地实施了Code
Review和结对编程。
总结第一轮实施敏捷的试点项目，并没有要求实施代码走查活动，项目负责人和开发人员也没有意识进行Code
Review。要么是找借口说进度太紧张时间不够用，要么是不知道如何进行代码走查。第一种纯粹是意识问题，要回答不知道怎么进行代码走查的问题则从代码走查的种类开始着手。代码走查分为两种：一种是交叉代码审查，自己的代码由他人来检查，就像检查作业一样；另一种是代码会审，就是以会议的形式，大家共同审核代码的质量。代码走查主要审查的内容包括：是否符合代码规范，确保所有人写的代码基本一致并符合代码规范；代码满足基本用户故事的要求，检查代码的逻辑实现，确认能实现用户故事；代码满足性能等非功能性需求，非功能性需求一般需要借助一定的工具和Code
Review人员的能力，针对编码中对于性能影响的瓶颈给出解决方案；代码简化，提高代码的可读性，能够用公用的方法和公用API实现，则无须每人定义自己的实现代码。
随便抽出某开发人员的1000行代码检查的结果是：代码注释不充分，很多实现逻辑的类和方法没有注释；有些代码性能差，频繁地读写磁盘IO；有些代码虽然实现了功能需求，但从逻辑上写得太死，不便于扩展；在约定使用统一代码的写日志功能代码作者定义了自己的代码来实现。看来为了提高质量，代码走查是实施敏捷项目管理一定要执行的工作。
4．被修订的测试报告
测试报告是集成测试阶段每天都需要测试工程师编写的一份重要的信息沟通工具，它的目的是让团队所有成员了解当前Sprint交付软件的质量情况，每个开发人员身上有多少未解决的Bug，以及交付模块的质量情况。回顾试点项目的项目测试报告，大概是从百度上搜索的模板，冗长而不知所云。报告中什么编写目的、背景、测试对象、测试概要、测试用例、测试环境等，光标题就会让人眼花缭乱。从正规性上讲，这样的测试报告提交给最终用户无可厚非，但是给团队内部看就没必要这样讲求全面性和规范性了。再引用敏捷思想"可用的软件重于完备的文档"。所以修订测试报告应该是为团队减轻负担、提高沟通效率的一项优先级非常高的优化活动。
问问团队需要什么样的报告。产品团队回答需要了解当前软件的质量来决策是否可发版，以及有些不好解决的缺陷拿出来让团队共同来决策Bug的处理策略。研发团队回答需要了解每个人身上有多少个未解决的缺陷，Bug整体解决情况和各模块的质量。测试团队关注的是Bug整体解决情况及分解下的按模块、按人员缺陷情况。统一思想后的测试报告包括一个测试情况的基本总结和三个部分。
基本情况总结是整个测试报告中最重要的部分，应该用粗体和红色来描述。要求尽量用一两句话描述清楚当前测试的总体情况。例如，当前测试遇到未解决的严重级别缺陷大于3个，不符合发版需求，其中组件下载功能如果点击取消，必崩。第一部分是Bug移除率的统计，其中累计移除率是了解当前Bug整体解决情况的最好的说明，如下表所示为2010年9月23日某项目测试统计数据。
……
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
